< draft-ietf-rtgwg-cl-requirement-05.txt   draft-ietf-rtgwg-cl-requirement-06.txt >
RTGWG C. Villamizar, Ed. RTGWG C. Villamizar, Ed.
Internet-Draft OCCNC, LLC Internet-Draft OCCNC, LLC
Intended status: Informational D. McDysan, Ed. Intended status: Informational D. McDysan, Ed.
Expires: August 2, 2012 S. Ning Expires: December 9, 2012 Verizon
S. Ning
Tata Communications
A. Malis A. Malis
Verizon Verizon
L. Yong L. Yong
Huawei USA Huawei USA
January 30, 2012 June 7, 2012
Requirements for MPLS Over a Composite Link Requirements for MPLS Over a Composite Link
draft-ietf-rtgwg-cl-requirement-05 draft-ietf-rtgwg-cl-requirement-06
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 6
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 August 2, 2012.
This Internet-Draft will expire on December 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Network Operator Functional Requirements . . . . . . . . . . . 5 4. Network Operator Functional Requirements . . . . . . . . . . . 5
4.1. Availability, Stability and Transient Response . . . . . . 5 4.1. Availability, Stability and Transient Response . . . . . . 5
4.2. Component Links Provided by Lower Layer Networks . . . . . 6 4.2. Component Links Provided by Lower Layer Networks . . . . . 6
4.3. Parallel Component Links with Different Characteristics . 7 4.3. Parallel Component Links with Different Characteristics . 8
5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 9 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 10
6. Management Requirements . . . . . . . . . . . . . . . . . . . 10 6. Management Requirements . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
10.3. Appendix References . . . . . . . . . . . . . . . . . . . 13 Appendix A. ITU-T G.800 Composite Link Definitions and
Appendix A. Existing Network Operator Practices and Protocol
Usage . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Existing Multipath Standards and Techniques . . . . . 14
Appendix C. ITU-T G.800 Composite Link Definitions and
Terminology . . . . . . . . . . . . . . . . . . . . . 14 Terminology . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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
done in terms of functional requirements that are as independent as done in terms of functional requirements that are as independent as
possible of protocol specifications (Section 4). For certain possible of protocol specifications (Section 4). For certain
functional requirements this document describes a set of derived functional requirements this document describes a set of derived
protocol requirements (Section 5). Three appendices provide protocol requirements (Section 5). Appendix A provides a summary of
supporting details as a summary of existing/prior operator approaches G.800 terminology used to define a composite link.
(Appendix A), a summary of implementation techniques and relevant
protocol standards (Appendix B), and a summary of G.800 terminology
used to define a composite link (Appendix C).
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Assumptions 2. Assumptions
The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797 The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797
[RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761], [RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761],
RFC 4762 [RFC4762]) and VPMS VPMS Framework RFC 4762 [RFC4762]) and VPMS VPMS Framework
[I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic [I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic
encapsulated by at least one MPLS label, and dynamically signaled encapsulated by at least one MPLS label (RFC 3032 [RFC3032]), and
MPLS or MPLS-TP LSPs and pseudowires. The MPLS LSPs supporting these dynamically signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036])
services may be pt-pt, pt-mpt, or mpt-mpt. or MPLS-TP LSPs (RFC 5921 [RFC5921]) and pseudowires (RFC 3985
[RFC3985]). The MPLS LSPs supporting these services may be point-to-
point, point-to-multipoint, or multipoint-to-multipoint.
The locations in a network where these requirements apply are a Label The locations in a network where these requirements apply are a Label
Edge Router (LER) or a Label Switch Router (LSR) as defined in RFC Edge Router (LER) or a Label Switch Router (LSR) as defined in RFC
3031 [RFC3031]. 3031 [RFC3031].
The IP DSCP cannot be used for flow identification since L3VPN The IP DSCP cannot be used for flow identification since L3VPN
requires Diffserv transparency (see RFC 4031 5.5.2 [RFC4031]), and in requires Diffserv transparency (see RFC 4031 5.5.2 [RFC4031]), and in
general network operators do not rely on the DSCP of Internet general network operators do not rely on the DSCP of Internet
packets. packets.
3. Definitions 3. Definitions
ITU-T G.800 Based Composite and Component Link Definitions: ITU-T G.800 Based Composite and Component Link Definitions:
Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite and Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite and
component links as summarized in Appendix C. The following component links as summarized in Appendix A. The following
definitions for composite and component links are derived from definitions for composite and component links are derived from
and intended to be consistent with the cited ITU-T G.800 and intended to be consistent with the cited ITU-T G.800
terminology. terminology.
Composite Link: A composite link is a logical link composed of a Composite Link: A composite link is a logical link composed of a
set of parallel point-to-point component links, where all set of parallel point-to-point component links, where all
links in the set share the same endpoints. A composite link links in the set share the same endpoints. A composite link
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 link (including one or
preserves ordering in the steady state. A component link may more link layer) or a logical link that preserves ordering in
have transient out of order events, but such events must not the steady state. A component link may have transient out of
exceed the network's specific NPO. Examples of a physical order events, but such events must not exceed the network's
link are: Lambda, Ethernet PHY, and OTN. Examples of a specific NPO. Examples of a physical link are: any set of
logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP. link layers over a WDM wavelength or any supportable
combination of Ethernet PHY, PPP, SONET or OTN over a
physical link. Examples of a logical link are: MPLS LSP,
Ethernet VLAN, MPLS-TP LSP. A set of link layers supported
over pseudowire is a logical link that appears to the client
to be a physical link.
Flow: A sequence of packets that must be transferred in order on one Flow: A sequence of packets that must be transferred in order on one
component link. 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
performance measures, principally availability, latency, and performance measures, principally availability, latency, and
delay variation. See Appendix A for more details. delay variation. See [I-D.symmvo-rtgwg-cl-use-cases] for more
details.
4. Network Operator Functional Requirements 4. Network Operator Functional Requirements
The Functional Requirements in this section are grouped in The Functional Requirements in this section are grouped in
subsections starting with the highest priority. subsections starting with the highest priority.
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.
provides references and a summary of service types requiring a range [I-D.symmvo-rtgwg-cl-use-cases] provides references and a summary of
of restoration times. service types requiring a range of restoration times.
FR#1 The solution SHALL provide a means to summarize some 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. A timeframe needed to meet the network performance objective. A
composite link CAN be announced in conjunction with detailed composite link CAN be announced in conjunction with detailed
parameters about its component links, such as bandwidth and parameters about its component links, such as bandwidth and
latency. The composite link SHALL behave as a single IGP latency. The composite link SHALL behave as a single IGP
adjacency. adjacency.
skipping to change at page 6, line 43 skipping to change at page 6, line 44
FR#5 Any automatic LSP routing and/or load balancing solutions MUST FR#5 Any automatic LSP routing and/or load balancing solutions MUST
not oscillate such that performance observed by users changes not oscillate such that performance observed by users changes
such that an NPO is violated. Since oscillation may cause such that an NPO is violated. Since oscillation may cause
reordering, there MUST be means to control the frequency of reordering, there MUST be means to control the frequency of
changing the component link over which a flow is placed. changing the component link over which a flow is placed.
FR#6 Management and diagnostic protocols MUST be able to operate FR#6 Management and diagnostic protocols MUST be able to operate
over composite links. over composite links.
Existing scaling techniques used in MPLS networks apply to MPLS
networks which support Composite Links. Scalability and stability
are covered in more detail in [I-D.so-yong-rtgwg-cl-framework].
4.2. Component Links Provided by Lower Layer Networks 4.2. Component Links Provided by Lower Layer Networks
Case 3 as defined in [ITU-T.G.800] involves a component link Case 3 as defined in [ITU-T.G.800] involves a component link
supporting an MPLS layer network over another lower layer network supporting an MPLS layer network over another lower layer network
(e.g., circuit switched or another MPLS network (e.g., MPLS-TP)). (e.g., circuit switched or another MPLS network (e.g., MPLS-TP)).
The lower layer network may change the latency (and/or other The lower layer network may change the latency (and/or other
performance parameters) seen by the MPLS layer network. Network performance parameters) seen by the MPLS layer network. Network
Operators have NPOs of which some components are based on performance Operators have NPOs of which some components are based on performance
parameters. Currently, there is no protocol for the lower layer parameters. Currently, there is no protocol for the lower layer
network to inform the higher layer network of a change in a network to inform the higher layer network of a change in a
performance parameter. Communication of the latency performance performance parameter. Communication of the latency performance
parameter is a very important requirement. Communication of other parameter is a very important requirement. Communication of other
performance parameters (e.g., delay variation) is desirable. performance parameters (e.g., delay variation) is desirable.
FR#7 In order to support network NPOs and provide acceptable user FR#7 In order to support network NPOs and provide acceptable user
experience, the solution SHALL specify a protocol means to experience, the solution SHALL specify a protocol means to
allow a lower layer server network to communicate latency to allow a lower layer server network to communicate latency to
the higher layer client network. the higher layer client network.
FR#8 The precision of latency reporting SHOULD be at least 10% of FR#8 The precision of latency reporting SHOULD be configurable. A
the one way latencies for latency of 1 ms or more. reasonable default SHOULD be provided. Implementations SHOULD
support precision of at least 10% of the one way latencies for
latency of 1 ms or more.
FR#9 The solution SHALL provide a means to limit the latency on a FR#9 The solution SHALL provide a means to limit the latency on a
per LSP basis between nodes within a network to meet an NPO per LSP basis between nodes within a network to meet an NPO
target when the path between these nodes contains one or more target when the path between these nodes contains one or more
pairs of nodes connected via a composite link. pairs of nodes connected via a composite link.
The NPOs differ across the services, and some services have The NPOs differ across the services, and some services have
different NPOs for different QoS classes, for example, one QoS different NPOs for different QoS classes, for example, one QoS
class may have a much larger latency bound than another. class may have a much larger latency bound than another.
Overload can occur which would violate an NPO parameter (e.g., Overload can occur which would violate an NPO parameter (e.g.,
loss) and some remedy to handle this case for a composite link loss) and some remedy to handle this case for a composite link
is required. is required.
FR#10 If the total demand offered by traffic flows exceeds the FR#10 If the total demand offered by traffic flows exceeds the
capacity of the composite link, the solution SHOULD define a capacity of the composite link, the solution SHOULD define a
means to cause the LSPs for some traffic flows to move to some means to cause the LSPs for some traffic flows to move to some
other point in the network that is not congested. These other point in the network that is not congested. These
"preempted LSPs" may not be restored if there is no "preempted LSPs" may not be restored if there is no
uncongested path in the network. uncongested path in the network.
The intent is to measure the predominant latency in uncongested
service provider networks, where geographic delay dominates and is on
the order of milliseconds or more. The argument for including
queuing delay is that it reflects the delay experienced by
applications. The argument against including queuing delay is that
it if used in routing decisions it can result in routing instability.
This tradeoff is discussed in detail in
[I-D.so-yong-rtgwg-cl-framework].
4.3. Parallel Component Links with Different Characteristics 4.3. Parallel Component Links with Different Characteristics
Corresponding to Case 1 of [ITU-T.G.800], as one means to provide Corresponding to Case 1 of [ITU-T.G.800], as one means to provide
high availability, network operators deploy a topology in the MPLS high availability, network operators deploy a topology in the MPLS
network using lower layer networks that have a certain degree of network using lower layer networks that have a certain degree of
diversity at the lower layer(s). Many techniques have been developed diversity at the lower layer(s). Many techniques have been developed
to balance the distribution of flows across component links that to balance the distribution of flows across component links that
connect the same pair of nodes. When the path for a flow can be connect the same pair of nodes. When the path for a flow can be
chosen from a set of candidate nodes connected via composite links, chosen from a set of candidate nodes connected via composite links,
other techniques have been developed. other techniques have been developed. Refer to the Appendices in
[I-D.symmvo-rtgwg-cl-use-cases] for a description of existing
techniques and a set of references.
FR#11 The solution SHALL measure traffic on a labeled traffic flow FR#11 The solution SHALL measure traffic on a labeled traffic flow
and dynamically select the component link on which to place and dynamically select the component link on which to place
this flow in order to balance the load so that no component this flow in order to balance the load so that no component
link in the composite link between a pair of nodes is link in the composite link between a pair of nodes is
overloaded. overloaded.
FR#12 When a traffic flow is moved from one component link to FR#12 When a traffic flow is moved from one component link to
another in the same composite link between a set of nodes (or another in the same composite link between a set of nodes (or
sites), it MUST be done so in a minimally disruptive manner. sites), it MUST be done so in a minimally disruptive manner.
When a flow is moved from a current link to a target link with
different latency, reordering can occur if the target link
latency is less than that of the current or clumping can occur
if target link latency is greater than that of the current.
Therefore, some flows (e.g., timing distribution, PW circuit
emulation) are quite sensitive to these effects, which may be
specified in an NPO or are needed to meet a user experience
objective (e.g. jitter buffer under/overrun).
FR#13 The solution SHALL provide a means to identify flows whose FR#13 The solution SHALL provide a means to identify flows whose
rearrangement frequency needs to be bounded by a configured rearrangement frequency needs to be bounded by a configured
value. value.
FR#14 The solution SHALL provide a means that communicates whether FR#14 The solution SHALL provide a means that communicates whether
the flows within an LSP can be split across multiple component the flows within an LSP can be split across multiple component
links. The solution SHOULD provide a means to indicate the links. The solution SHOULD provide a means to indicate the
flow identification field(s) which can be used along the flow flow identification field(s) which can be used along the flow
path which can be used to perform this function. path which can be used to perform this function.
skipping to change at page 9, line 24 skipping to change at page 9, line 35
composite link. If this option is not exercised, then an LSP composite link. If this option is not exercised, then an LSP
that is bound to a composite link may be bound to any that is bound to a composite link may be bound to any
component link matching all other signaled requirements, and component link matching all other signaled requirements, and
different directions of a bidirectional LSP can be bound to different directions of a bidirectional LSP can be bound to
different component links. different component links.
FR#22 The solution MUST support a means to indicate that both FR#22 The solution MUST support a means to indicate that both
directions of co-routed bidirectional LSP MUST be bound to the directions of co-routed bidirectional LSP MUST be bound to the
same component link. same component link.
A minimally disruptive change implies that as little disruption as is
practical occurs. Such a change can be achieved with zero packet
loss. A delay discontinuity may occur, which is considered to be a
minimally disruptive event for most services if this type of event is
sufficiently rare. A delay discontinuity is an example of a
minimally disruptive behavior corresponding to current techniques.
A delay discontinuity is an isolated event which may greatly exceed
the normal delay variation (jitter). A delay discontinuity has the
following effect. When a flow is moved from a current link to a
target link with lower latency, reordering can occur. When a flow is
moved from a current link to a target link with a higher latency, a
time gap can occur. Some flows (e.g., timing distribution, PW
circuit emulation) are quite sensitive to these effects. A delay
discontinuity can also cause a jitter buffer underrun or overrun
affecting user experience in real time voice services (causing an
audible click). These sensitivities may be specified in an NPO.
5. Derived Requirements 5. Derived Requirements
This section takes the next step and derives high-level requirements This section takes the next step and derives high-level requirements
on protocol specification from the functional requirements. on protocol specification from the functional requirements.
DR#1 The solution SHOULD attempt to extend existing protocols DR#1 The solution SHOULD attempt to extend existing protocols
wherever possible, developing a new protocol only if this adds wherever possible, developing a new protocol only if this adds
a significant set of capabilities. a significant set of capabilities.
DR#2 A solution SHOULD extend LDP capabilities to meet functional DR#2 A solution SHOULD extend LDP capabilities to meet functional
skipping to change at page 10, line 5 skipping to change at page 10, line 30
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 SHOULD 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.
Examples of advertisement update triggering events to be Examples of advertisement update triggering events to be
considered include: LSP establishment/release, changes in 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),
skipping to change at page 11, line 8 skipping to change at page 11, line 32
MR#4 Management Plane MUST be able to trace which component link a MR#4 Management Plane MUST be able to trace which component link a
LSP is assigned to and monitor individual component link and LSP is assigned to and monitor individual component link and
composite link performance. composite link performance.
MR#5 Management Plane MUST be able to verify connectivity over each MR#5 Management Plane MUST be able to verify connectivity over each
individual component link within a composite link. individual component link within a composite link.
MR#6 Management Plane SHOULD provide the means for an operator to MR#6 Management Plane SHOULD provide the means for an operator to
initiate an optimization process. initiate an optimization process.
MR#7 Any statement which requires the solution to support some new
functionality through use of the words new functionality,
SHOULD be interpretted as follows. The implementation either
MUST or SHOULD support the new functionality depending on the
use of either MUST or SHOULD in the requirements statement.
The implementation SHOULD in most or all cases allow any new
functionality to be individually enabled or disabled through
configuration.
7. Acknowledgements 7. 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.
A rewrite of this document occurred after the IETF77 meeting. A rewrite of this document occurred after the IETF77 meeting.
Dimitri Papadimitriou, Lou Berger, Tony Li, the WG chairs John Scuder Dimitri Papadimitriou, Lou Berger, Tony Li, the WG chairs John Scuder
and Alex Zinin, and others provided valuable guidance prior to and at and Alex Zinin, and others provided valuable guidance prior to and at
the IETF77 RTGWG meeting. the IETF77 RTGWG meeting.
Tony Li and John Drake have made numerous valuable comments on the Tony Li and John Drake have made numerous valuable comments on the
RTGWG mailing list that are reflected in versions following the RTGWG mailing list that are reflected in versions following the
IETF77 meeting. IETF77 meeting.
Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG
mailing list after IETF82 that identified a new requirement.
Iftekhar Hussain made numerous valuable comments on the RTGWG mailing
list that resulted in improvements to document clarity.
In the interest of full disclosure of affiliation and in the interest
of acknowledging sponsorship, past affiliations of authors are noted.
Much of the work done by Ning So occurred while Ning was at Verizon.
Much of the work done by Curtis Villamizar occurred while at
Infinera. Infinera continues to sponsor this work on a consulting
basis.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
This document specifies a set of requirements. The requirements This document specifies a set of requirements. The requirements
themselves do not pose a security threat. If these requirements are themselves do not pose a security threat. If these requirements are
met using MPLS signaling as commonly practiced today with met using MPLS signaling as commonly practiced today with
authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP, authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP,
skipping to change at page 12, line 11 skipping to change at page 13, line 11
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 10.2. Informative References
[I-D.ietf-l2vpn-vpms-frmwk-requirements] [I-D.ietf-l2vpn-vpms-frmwk-requirements]
Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", Private Multicast Service (VPMS)",
draft-ietf-l2vpn-vpms-frmwk-requirements-03 (work in draft-ietf-l2vpn-vpms-frmwk-requirements-04 (work in
progress), July 2010. progress), July 2011.
[I-D.so-yong-rtgwg-cl-framework]
So, N., McDysan, D., Osborne, E., Yong, L., and C.
Villamizar, "Composite Link Framework in Multi Protocol
Label Switching (MPLS)",
draft-so-yong-rtgwg-cl-framework-05 (work in progress),
March 2012.
[I-D.symmvo-rtgwg-cl-use-cases]
Malis, A., Villamizar, C., McDysan, D., Yong, L., and N.
So, "Composite Link USe Cases and Design Considerations",
draft-symmvo-rtgwg-cl-use-cases-00 (work in progress),
February 2012.
[ITU-T.G.800] [ITU-T.G.800]
ITU-T, "Unified functional architecture of transport ITU-T, "Unified functional architecture of transport
networks", 2007, <http://www.itu.int/rec/T-REC-G/ networks", 2007, <http://www.itu.int/rec/T-REC-G/
recommendation.asp?parent=T-REC-G.800>. recommendation.asp?parent=T-REC-G.800>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003. protocols", RFC 3468, February 2003.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Provisioned Virtual Private Networks (PPVPN)", RFC 3809, Edge (PWE3) Architecture", RFC 3985, March 2005.
June 2004.
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer
3 Provider Provisioned Virtual Private Networks (PPVPNs)", 3 Provider Provisioned Virtual Private Networks (PPVPNs)",
RFC 4031, April 2005. RFC 4031, April 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006. Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private Networks",
RFC 4665, September 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", (VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007. RFC 4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
[RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider [RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider
Edge to Provider Edge (PE-PE) Generic Routing Edge to Provider Edge (PE-PE) Generic Routing
Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private
Networks", RFC 4797, January 2007. Networks", RFC 4797, January 2007.
[RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", Specification", RFC 5036, October 2007.
RFC 5254, October 2008.
10.3. Appendix References
[I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS PSN", draft-ietf-pwe3-fat-pw-03 (work in
progress), January 2010.
[RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The
PPP Multilink Protocol (MP)", RFC 1717, November 1994.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, June 2007.
Appendix A. Existing Network Operator Practices and Protocol Usage
The network operator practices appendix has been moved to a separate
document. When that document has an XML I-D tag the references to
this appendix will be changed to that document and this appendix will
be deleted.
Appendix B. Existing Multipath Standards and Techniques
The multipath standards and techniques appendix has been moved to a [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
separate document. When that document has an XML I-D tag the Berger, "A Framework for MPLS in Transport Networks",
references to this appendix will be changed to that document and this RFC 5921, July 2010.
appendix will be deleted.
Appendix C. ITU-T G.800 Composite Link Definitions and Terminology Appendix A. ITU-T G.800 Composite Link Definitions and Terminology
Composite Link: Composite Link:
Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite link Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite link
in terms of three cases, of which the following two are relevant in terms of three cases, of which the following two are relevant
(the one describing inverse (TDM) multiplexing does not apply). (the one describing inverse (TDM) multiplexing does not apply).
Note that these case definitions are taken verbatim from section Note that these case definitions are taken verbatim from section
6.9, "Layer Relationships". 6.9, "Layer Relationships".
Case 1: "Multiple parallel links between the same subnetworks Case 1: "Multiple parallel links between the same subnetworks
can be bundled together into a single composite link. Each can be bundled together into a single composite link. Each
skipping to change at page 15, line 33 skipping to change at page 15, line 42
Email: curtis@occnc.com Email: curtis@occnc.com
Dave McDysan (editor) Dave McDysan (editor)
Verizon Verizon
22001 Loudoun County PKWY 22001 Loudoun County PKWY
Ashburn, VA 20147 Ashburn, VA 20147
Email: dave.mcdysan@verizon.com Email: dave.mcdysan@verizon.com
So Ning So Ning
Verizon Tata Communications
2400 N. Glenville Ave.
Richardson, TX 75082
Phone: +1 972-729-7905
Email: ning.so@verizonbusiness.com
Email: ning.so@tatacommunications.com
Andrew Malis Andrew Malis
Verizon Verizon
117 West St. 117 West St.
Waltham, MA 02451 Waltham, MA 02451
Phone: +1 781-466-2362 Phone: +1 781-466-2362
Email: andrew.g.malis@verizon.com Email: andrew.g.malis@verizon.com
Lucy Yong Lucy Yong
Huawei USA Huawei USA
1700 Alma Dr. Suite 500 1700 Alma Dr. Suite 500
Plano, TX 75075 Plano, TX 75075
Phone: +1 469-229-5387 Phone: +1 469-229-5387
Email: lucyyong@huawei.com Email: lucyyong@huawei.com
 End of changes. 32 change blocks. 
126 lines changed or deleted 134 lines changed or added

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