draft-ietf-rtgwg-cl-requirement-02.txt   draft-ietf-rtgwg-cl-requirement-03.txt 
RTGWG C. Villamizar, Ed. RTGWG C. Villamizar, Ed.
Internet-Draft Infinera Corporation Internet-Draft Infinera Corporation
Intended status: Informational D. McDysan, Ed. Intended status: Informational D. McDysan, Ed.
Expires: April 14, 2011 S. Ning Expires: July 14, 2011 S. Ning
A. Malis A. Malis
Verizon Verizon
L. Yong L. Yong
Huawei USA Huawei USA
October 11, 2010 January 10, 2011
Requirements for MPLS Over a Composite Link Requirements for MPLS Over a Composite Link
draft-ietf-rtgwg-cl-requirement-02 draft-ietf-rtgwg-cl-requirement-03
Abstract Abstract
There is often a need to provide large aggregates of bandwidth that There is often a need to provide large aggregates of bandwidth that
are best provided using parallel links between routers or MPLS LSR. are best provided using parallel links between routers or MPLS LSR.
In core networks there is often no alternative since the aggregate In core networks there is often no alternative since the aggregate
capacities of core networks today far exceed the capacity of a single capacities of core networks today far exceed the capacity of a single
physical link or single packet processing element. physical link or single packet processing element.
The presence of parallel links, with each link potentially comprised The presence of parallel links, with each link potentially comprised
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2011. This Internet-Draft will expire on July 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 28 skipping to change at page 3, line 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
9.3. Appendix References . . . . . . . . . . . . . . . . . . . 12 9.3. Appendix References . . . . . . . . . . . . . . . . . . . 12
Appendix A. More Details on Existing Network Operator Appendix A. More Details on Existing Network Operator
Practices and Protocol Usage . . . . . . . . . . . . 13 Practices and Protocol Usage . . . . . . . . . . . . 13
Appendix B. Existing Multipath Standards and Techniques . . . . . 15 Appendix B. Existing Multipath Standards and Techniques . . . . . 15
B.1. Common Multpath Load Spliting Techniques . . . . . . . . . 16 B.1. Common Multpath Load Spliting Techniques . . . . . . . . . 16
B.2. Simple and Adaptive Load Balancing Multipath . . . . . . . 17 B.2. Simple and Adaptive Load Balancing Multipath . . . . . . . 17
B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 18 B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 17
B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 18 B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 18
Appendix C. ITU-T G.800 Composite Link Definitions and Appendix C. ITU-T G.800 Composite Link Definitions and
Terminology . . . . . . . . . . . . . . . . . . . . . 18 Terminology . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The purpose of this document is to describe why network operators The purpose of this document is to describe why network operators
require certain functions in order to solve certain business problems require certain functions in order to solve certain business problems
(Section 2). The intent is to first describe why things need to be (Section 2). The intent is to first describe why things need to be
skipping to change at page 5, line 19 skipping to change at page 5, line 19
may itself be a component of another composite link, but only may itself be a component of another composite link, but only
a strict hierarchy of links is allowed. a strict hierarchy of links is allowed.
Component Link: A point-to-point physical or logical link that Component Link: A point-to-point physical or logical link that
preserves ordering in the steady state. A component link may preserves ordering in the steady state. A component link may
have transient out of order events, but such events must not have transient out of order events, but such events must not
exceed the network's specific NPO. Examples of a physical exceed the network's specific NPO. Examples of a physical
link are: Lambda, Ethernet PHY, and OTN. Examples of a link are: Lambda, Ethernet PHY, and OTN. Examples of a
logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP. logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP.
Flow: A sequence of packets that must be transferred in order. Flow: A sequence of packets that must be transferred in order on one
component link.
Flow identification: The label stack and other information that Flow identification: The label stack and other information that
uniquely identifies a flow. Other information in flow uniquely identifies a flow. Other information in flow
identification may include an IP header, PW control word, identification may include an IP header, PW control word,
Ethernet MAC address, etc. Note that an LSP may contain one or Ethernet MAC address, etc. Note that an LSP may contain one or
more Flows or an LSP may be equivalent to a Flow. Flow more Flows or an LSP may be equivalent to a Flow. Flow
identification is used to locally select a component link, or a identification is used to locally select a component link, or a
path through the network toward the destination. path through the network toward the destination.
Network Performance Objective (NPO): Numerical values for Network Performance Objective (NPO): Numerical values for
skipping to change at page 6, line 5 skipping to change at page 6, line 5
4.1. Availability, Stability and Transient Response 4.1. Availability, Stability and Transient Response
Limiting the period of unavailability in response to failures or Limiting the period of unavailability in response to failures or
transient events is extremely important as well as maintaining transient events is extremely important as well as maintaining
stability. The transient period between some service disrupting stability. The transient period between some service disrupting
event and the convergence of the routing and/or signaling protocols event and the convergence of the routing and/or signaling protocols
MUST occur within a time frame specified by NPO values. Appendix A MUST occur within a time frame specified by NPO values. Appendix A
provides references and a summary of service types requiring a range provides references and a summary of service types requiring a range
of restoration times. of restoration times.
FR#1 The solution SHALL provide a means to summarize routing FR#1 The solution SHALL provide a means to summarize some routing
advertisements regarding the characteristics of a composite advertisements regarding the characteristics of a composite
link such that the routing protocol converges within the link such that the routing protocol converges within the
timeframe needed to meet the network performance objective. timeframe needed to meet the network performance objective. A
composite link CAN be announced in conjunction with detailed
parameters about its component links, such as bandwidth and
latency. The composite link SHALL behave as a single IGP
adjacency.
FR#2 The solution SHALL ensure that all possible restoration FR#2 The solution SHALL ensure that all possible restoration
operations happen within the timeframe needed to meet the NPO. operations happen within the timeframe needed to meet the NPO.
The solution may need to specify a means for aggregating The solution may need to specify a means for aggregating
signaling to meet this requirement. signaling to meet this requirement.
FR#3 The solution SHALL provide a mechanism to select a path for a FR#3 The solution SHALL provide a mechanism to select a path for a
flow across a network that contains a number of paths comprised flow across a network that contains a number of paths comprised
of pairs of nodes connected by composite links in such a way as of pairs of nodes connected by composite links in such a way as
to automatically distribute the load over the network nodes to automatically distribute the load over the network nodes
skipping to change at page 9, line 42 skipping to change at page 9, line 42
supported as independently of signaling protocol as possible. supported as independently of signaling protocol as possible.
DR#4 When the nodes connected via a composite link are in the same DR#4 When the nodes connected via a composite link are in the same
MPLS network topology, the solution MAY define extensions to MPLS network topology, the solution MAY define extensions to
the IGP. the IGP.
DR#5 When the nodes are connected via a composite link are in DR#5 When the nodes are connected via a composite link are in
different MPLS network topologies, the solution SHALL NOT rely different MPLS network topologies, the solution SHALL NOT rely
on extensions to the IGP. on extensions to the IGP.
DR#6 The Solution SHALL support composite link IGP advertisement DR#6 The Solution SHOULD support composite link IGP advertisement
that results in convergence time better than that of that results in convergence time better than that of
advertising the individual component links. The solution SHALL advertising the individual component links. The solution SHALL
be designed so that it represents the range of capabilities of be designed so that it represents the range of capabilities of
the individual component links such that functional the individual component links such that functional
requirements are met, and also minimizes the frequency of requirements are met, and also minimizes the frequency of
advertisement updates which may cause IGP convergence to occur. advertisement updates which may cause IGP convergence to occur.
One solution approach is to summarize the characteristics of Examples of advertisement update triggering events to be
the component links in IGP advertisements; however, the intent considered include: LSP establishment/release, changes in
of the above requirement is not to specify the form of a
solution. Examples of advertisement update triggering events
to be considered include: LSP establishment/release, changes in
component link characteristics (e.g., latency, up/down state), component link characteristics (e.g., latency, up/down state),
and/or bandwidth utilization. and/or bandwidth utilization.
DR#7 When a worst case failure scenario occurs,the resulting number DR#7 When a worst case failure scenario occurs, the number of
of links advertised in the IGP causes IGP convergence to occur,
causing a period of unavailability as perceived by users. The
convergence time of the solution MUST meet the SLA objective
for the duration of unavailability.
DR#8 When a worst case failure scenario occurs, the number of
RSVP-TE LSPs to be resignaled will cause a period of RSVP-TE LSPs to be resignaled will cause a period of
unavailability as perceived by users. The resignaling time of unavailability as perceived by users. The resignaling time of
the solution MUST meet the NPO objective for the duration of the solution MUST meet the NPO objective for the duration of
unavailability. The resignaling time of the solution MUST not unavailability. The resignaling time of the solution MUST not
increase significantly as compared with current methods. increase significantly as compared with current methods.
6. Acknowledgements 6. Acknowledgements
Frederic Jounay of France Telecom and Yuji Kamite of NTT Frederic Jounay of France Telecom and Yuji Kamite of NTT
Communications Corporation co-authored a version of this document. Communications Corporation co-authored a version of this document.
 End of changes. 12 change blocks. 
22 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/