< draft-ietf-rtgwg-cl-requirement-01.txt   draft-ietf-rtgwg-cl-requirement-02.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: January 9, 2011 S. Ning Expires: April 14, 2011 S. Ning
A. Malis A. Malis
Verizon Verizon
L. Yong L. Yong
Huawei USA Huawei USA
July 8, 2010 October 11, 2010
Requirements for MPLS Over a Composite Link Requirements for MPLS Over a Composite Link
draft-ietf-rtgwg-cl-requirement-01 draft-ietf-rtgwg-cl-requirement-02
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
is 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. Furthermore, physical link or single packet processing element.
links may be composed of network elements operating across multiple
layers.
The presence of parallel links, potentially comprised of multiple The presence of parallel links, with each link potentially comprised
layers has resulted in a additional requirements. Certain services of multiple layers has resulted in additional requirements. Certain
may benefit from being restricted to a subset of the set of composite services may benefit from being restricted to a subset of the
link component links or a specific component link, where component component links or a specific component link, where component link
link characteristics, such as latency, differ. Certain services characteristics, such as latency, differ. Certain services require
require that LSP be treated as atomic and avoid reordering. Other that an LSP be treated as atomic and avoid reordering. Other
services will continue to require only that reordering not occur with services will continue to require only that reordering not occur
a microflow as is current practice. within a microflow as is current practice.
Current practice related to multipath is described briefly in an Current practice related to multipath is described briefly in an
appendix. appendix.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 9, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 15 skipping to change at page 3, line 15
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 . 7
5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 8 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
9.3. Appendix References . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . 12 Practices and Protocol Usage . . . . . . . . . . . . 13
Appendix B. Existing Multipath Standards and Techniques . . . . . 14 Appendix B. Existing Multipath Standards and Techniques . . . . . 15
B.1. Common Multpath Load Spliting Techniques . . . . . . . . . 15 B.1. Common Multpath Load Spliting Techniques . . . . . . . . . 16
B.2. Simple and Adaptive Load Balancing Multipath . . . . . . . 16 B.2. Simple and Adaptive Load Balancing Multipath . . . . . . . 17
B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 16 B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 18
B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . 17 Terminology . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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
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). Three appendices provide
supporting details as a summary of existing/prior operator supporting details as a summary of existing/prior operator approaches
approaches, a summary of implementation techniques and relevant (Appendix A), a summary of implementation techniques and relevant
protocol standards, and a summary of G.800 terminology used to define protocol standards (Appendix B), and a summary of G.800 terminology
the concept of a composite link. (Appendix B). 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, L2VPN (VPWS and VPLS), Internet The services supported include L3VPN RFC 4364 [RFC4364], RFC 4797
traffic encapsulated by at least one MPLS label, and dynamically [RFC4797]L2VPN RFC 4664 [RFC4664] (VPWS, VPLS (RFC 4761 [RFC4761],
signaled MPLS-TP LSPs and pseudowires. The MPLS LSPs supporting RFC 4762 [RFC4762]) and VPMS VPMS Framework
these services may be pt-pt, pt-mpt, or mpt-mpt. [I-D.ietf-l2vpn-vpms-frmwk-requirements]), Internet traffic
encapsulated by at least one MPLS label, and dynamically signaled
MPLS or MPLS-TP LSPs and pseudowires. The MPLS LSPs supporting these
services may be pt-pt, pt-mpt, or mpt-mpt.
The location 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
Composite Link: 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 link Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite and
as summarized in Appendix Appendix C. The following definitions component links as summarized in Appendix C. The following
map the ITU-T G.800 terminology into IETF terminology which is definitions for composite and component links are derived from
used in this document. and intended to be consistent with the cited ITU-T G.800
terminology.
Multiple parallel links: When multiple parallel component links
between the an LER/LSR and another LER/LSR.
Multi-layer Component Link: A component link that is formed by Composite Link: A composite link is a logical link composed of a
other network elements at other layers. set of parallel point-to-point component links, where all
links in the set share the same endpoints. A composite link
may itself be a component of another composite link, but only
a strict hierarchy of links is allowed.
Component Link: A physical link (e.g., Lambda, Ethernet PHY, SONET/ Component Link: A point-to-point physical or logical link that
SDH, OTN, etc.) with packet transport capability, or a logical preserves ordering in the steady state. A component link may
link (e.g., MPLS LSP, Ethernet VLAN, MPLS-TP LSP, etc.) have transient out of order events, but such events must not
exceed the network's specific NPO. Examples of a physical
link are: Lambda, Ethernet PHY, and OTN. Examples of a
logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP.
Flow: A sequence of packets that must be transferred on one Flow: A sequence of packets that must be transferred in order.
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
performance measures, principally availability, latency, and
delay variation. See Appendix A 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 SLA objectives. The MUST occur within a time frame specified by NPO values. Appendix A
timeframes range from rapid restoration, on the order of 100 ms or provides references and a summary of service types requiring a range
less (e.g., for VPWS), to several minutes (e.g., for L3VPN) and may of restoration times.
differ among the set of customers within a single service.
FR#1 The solution SHALL provide a means to summarize routing FR#1 The solution SHALL provide a means to summarize routing
advertisements regarding the characteristics of a composite advertisements regarding the characteristics of a composite
link such that the routing protocol convergence within the link such that the routing protocol converges within the
timeframe needed to meet the SLA objective.. timeframe needed to meet the network performance objective.
FR#2 The solution SHALL provide a means for aggregating signaling FR#2 The solution SHALL ensure that all possible restoration
such that in response to a failure in the worst case cross operations happen within the timeframe needed to meet the NPO.
section of the network that MPLS LSPs are restored within the The solution may need to specify a means for aggregating
timeframe needed to meet the SLA objective. signaling to meet this requirement.
FR#3 The solution SHALL provide to select a path for a flow across a FR#3 The solution SHALL provide a mechanism to select a path for a
network that contains a number of paths comprised of pairs of flow across a network that contains a number of paths comprised
nodes connected by composite links in such a way as to of pairs of nodes connected by composite links in such a way as
automatically distribute the load over the network nodes to automatically distribute the load over the network nodes
connected by composite links while meeting all of the other connected by composite links while meeting all of the other
mandatory requirements stated above. The solution SHOULD work mandatory requirements stated above. The solution SHOULD work
in a manner similar to that when the characteristics of the in a manner similar to that of current networks without any
individual component links are advertised. composite link protocol enhancements when the characteristics
of the individual component links are advertised.
FR#4 If extensions to existing protocols are specified and/or new FR#4 If extensions to existing protocols are specified and/or new
protocols are defined, then the solution SHOULD provide a means protocols are defined, then the solution SHOULD provide a means
for a network operator to migrate an existing deployment in a for a network operator to migrate an existing deployment in a
minimally disruptive manner. minimally disruptive manner.
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 SLA 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.
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 SLAs 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 SLAs 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 at least 10% of
the one way latency for latency of 1 ms or more. 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 SLA 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 SLAs differ across the services, and some services have The NPOs differ across the services, and some services have
different SLAs 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 SLA 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 loss) and some remedy to handle this case for a composite link
link. 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.
4.3. Parallel Component Links with Different Characteristics 4.3. Parallel Component Links with Different Characteristics
skipping to change at page 7, line 52 skipping to change at page 8, line 15
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 When a flow is moved from a current link to a target link with
different latency, reordering can occur if the target link different latency, reordering can occur if the target link
latency is less than that of the current or clumping can occur latency is less than that of the current or clumping can occur
if target link latency is greater than that of the current. if target link latency is greater than that of the current.
Therefore, some flows (e.g., timing distribution, PW circuit Therefore, some flows (e.g., timing distribution, PW circuit
emulation) are quite sensitive to these effects, which may be emulation) are quite sensitive to these effects, which may be
specified in an SLA or are needed to meet a user experience specified in an NPO or are needed to meet a user experience
objective (e.g. jitter buffer under/overrun). 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
skipping to change at page 8, line 28 skipping to change at page 8, line 40
value. value.
FR#16 The solution SHALL provide a means to indicate that a traffic FR#16 The solution SHALL provide a means to indicate that a traffic
flow shall select a component link with a maximum acceptable flow shall select a component link with a maximum acceptable
latency value as specified by protocol. latency value as specified by protocol.
FR#17 The solution SHALL provide a means to indicate that a traffic FR#17 The solution SHALL provide a means to indicate that a traffic
flow shall select a component link with a maximum acceptable flow shall select a component link with a maximum acceptable
delay variation value as specified by protocol. delay variation value as specified by protocol.
FR#18 The solution SHALL provide a local means to a node which FR#18 The solution SHALL provide a means local to a node that
automatically distribute flows across the component links in automatically distributes flows across the component links in
the composite link that connects to the other node such that the composite link such that NPOs are met.
SLA objectives are met.
FR#19 The solution SHALL provide a means to distribute flows from a FR#19 The solution SHALL provide a means to distribute flows from a
single LSP across multiple component links to handle at least single LSP across multiple component links to handle at least
the case where the traffic carried in an LSP exceeds that of the case where the traffic carried in an LSP exceeds that of
any component link in the composite link. any component link in the composite link. As defined in
section 3, a flow is a sequence of packets that must be
transferred on one component link.
FR#20 The solution SHOULD support the use case where a composite
link itself is a component link for a higher order composite
link. For example, a composite link comprised of MPLS-TP bi-
directional tunnels viewed as logical links could then be used
as a component link in yet another composite link that
connects MPLS routers.
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.
skipping to change at page 9, line 21 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 When a worst case failure scenario occurs,the resulting number DR#6 The Solution SHALL support composite link IGP advertisement
of links advertised in the IGP causes IGP convergence to occur, that results in convergence time better than that of
causing a period of unavailability as perceived by users. The advertising the individual component links. The solution SHALL
convergence time of the solution MUST meet the SLA objective be designed so that it represents the range of capabilities of
for the duration of unavailability. the individual component links such that functional
requirements are met, and also minimizes the frequency of
advertisement updates which may cause IGP convergence to occur.
DR#7 The Solution SHALL summarize the characteristics of the One solution approach is to summarize the characteristics of
component links as a composite link IGP advertisement that the component links in IGP advertisements; however, the intent
results in convergence time better than that of advertising the of the above requirement is not to specify the form of a
individual component links. This summary SHALL be designed so solution. Examples of advertisement update triggering events
that it represents the range of capabilities of the individual to be considered include: LSP establishment/release, changes in
component links such that functional requirements are met, and component link characteristics (e.g., latency, up/down state),
also minimizes the frequency of advertisement updates which may and/or bandwidth utilization.
cause IGP convergence to occur. Examples of advertisement
update tiggering events to be considered include: LSP
establishment/release, changes in component link
characteristics (e.g., latency, up/down state), and/or
bandwidth utilization.
DR#8 When a worst case failure scenario occurs,the resulting number DR#7 When a worst case failure scenario occurs,the resulting number
of links advertised in the IGP causes IGP convergence to occur, of links advertised in the IGP causes IGP convergence to occur,
causing a period of unavailability as perceived by users. The causing a period of unavailability as perceived by users. The
convergence time of the solution MUST meet the SLA objective convergence time of the solution MUST meet the SLA objective
for the duration of unavailability. for the duration of unavailability.
DR#9 When a worst case failure scenario occurs, the number of 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 SLA 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.
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
skipping to change at page 11, line 7 skipping to change at page 11, line 22
9. References 9. References
9.1. Normative References 9.1. Normative References
[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.
9.2. Informative References 9.2. Informative References
[I-D.ietf-l2vpn-vpms-frmwk-requirements]
Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)",
draft-ietf-l2vpn-vpms-frmwk-requirements-03 (work in
progress), July 2010.
[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. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
skipping to change at page 11, line 31 skipping to change at page 12, line 6
protocols", RFC 3468, February 2003. protocols", RFC 3468, February 2003.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider [RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC 3809, Provisioned Virtual Private Networks (PPVPN)", RFC 3809,
June 2004. 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
Networks (VPNs)", RFC 4364, February 2006.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private Networks", Layer 2 Provider-Provisioned Virtual Private Networks",
RFC 4665, September 2006. RFC 4665, September 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling",
RFC 4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007.
[RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider
Edge to Provider Edge (PE-PE) Generic Routing
Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private
Networks", RFC 4797, January 2007.
[RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for
Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)",
RFC 5254, October 2008. RFC 5254, October 2008.
9.3. Appendix References 9.3. Appendix References
[I-D.ietf-pwe3-fat-pw] [I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS PSN", draft-ietf-pwe3-fat-pw-03 (work in over an MPLS PSN", draft-ietf-pwe3-fat-pw-03 (work in
progress), January 2010. progress), January 2010.
[IEEE-802.1AX] [IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
Standard for Local and Metropolitan Area Networks - Link Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2006, <http://standards.ieee.org/getieee802/ Aggregation", 2006, <http://standards.ieee.org/getieee802/
download/802.1AX-2008.pdf>. download/802.1AX-2008.pdf>.
[ITU-T.Y.1540]
ITU-T, "Internet protocol data communication service - IP
packet transfer and availability performance parameters",
2007, <http://www.itu.int/rec/T-REC-Y.1540/en>.
[ITU-T.Y.1541] [ITU-T.Y.1541]
ITU-T, "Network performance objectives for IP-based ITU-T, "Network performance objectives for IP-based
services", 2006, <http://www.itu.int/rec/T-REC-Y.1541/en>. services", 2006, <http://www.itu.int/rec/T-REC-Y.1541/en>.
[RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The [RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The
PPP Multilink Protocol (MP)", RFC 1717, November 1994. PPP Multilink Protocol (MP)", RFC 1717, November 1994.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
skipping to change at page 12, line 45 skipping to change at page 13, line 45
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, June 2007. RFC 4928, June 2007.
Appendix A. More Details on Existing Network Operator Practices and Appendix A. More Details on Existing Network Operator Practices and
Protocol Usage Protocol Usage
Network operators have SLAs for services that are comprised of Often, network operators have a contractual Service Level Agreement
numerical values for performance measures, principally availability, (SLA) with customers for services that are comprised of numerical
latency, delay variation. See [ITU-T.Y.1541], RFC 3809, Section 4.9 values for performance measures, principally availability, latency,
[RFC3809] for examples of the form of such SLAs. Note that the delay variation. Additionally, network operators may have Service
numerical values of Y.1541 span multiple networks and may be looser Level Sepcification (SLS) that is for internal use by the operator.
than network operator SLAs. Applications and acceptable user See [ITU-T.Y.1540], [ITU-T.Y.1541], RFC3809, Section 4.9 [RFC3809]
experience have a relationship to these performance parameters. for examples of the form of such SLA and SLS specifications. In this
document we use the term Network Performance Objective (NPO) as
defined in section 5 of [ITU-T.Y.1541] since the SLA and SLS measures
have network operator and service specific implications. Note that
the numerical NPO values of Y.1540 and Y.1541 span multiple networks
and may be looser than network operator SLA or SLS objectives.
Applications and acceptable user experience have an important
relationship to these performance parameters.
Consider latency as an example. In some cases, minimizing latency Consider latency as an example. In some cases, minimizing latency
relates directly to the best customer experience (e.g., in TCP closer relates directly to the best customer experience (e.g., in TCP closer
is faster). I other cases, user experience is relatively insensitive is faster). I other cases, user experience is relatively insensitive
to latency, up to a specific limit at which point user perception of to latency, up to a specific limit at which point user perception of
quality degrades significantly (e.g., interactive human voice and quality degrades significantly (e.g., interactive human voice and
multimedia conferencing). A number of SLAs have. a bound on point- multimedia conferencing). A number of NPOs have. a bound on point-
point latency, and as long as this bound is met, the SLA is met -- point latency, and as long as this bound is met, the NPO is met --
decreasing the latency is not necessary. In some SLAs, if the decreasing the latency is not necessary. In some NPOs, if the
specified latency is not met, the user considers the service as specified latency is not met, the user considers the service as
unavailable. An unprotected LSP can be manually provisioned on a set unavailable. An unprotected LSP can be manually provisioned on a set
of to meet this type of SLA, but this lowers availability since an of to meet this type of NPO, but this lowers availability since an
alternate route that meets the latency SLA cannot be determined. alternate route that meets the latency NPO cannot be determined.
Historically, when an IP/MPLS network was operated over a lower layer Historically, when an IP/MPLS network was operated over a lower layer
circuit switched network (e.g., SONET rings), a change in latency circuit switched network (e.g., SONET rings), a change in latency
caused by the lower layer network (e.g., due to a maintenance action caused by the lower layer network (e.g., due to a maintenance action
or failure) this was not known to the MPLS network. This resulted in or failure) this was not known to the MPLS network. This resulted in
latency affecting end user experience, sometimes violating SLAs or latency affecting end user experience, sometimes violating NPOs or
resulting in user complaints. resulting in user complaints.
A response to this problem was to provision IP/MPLS networks over A response to this problem was to provision IP/MPLS networks over
unprotected circuits and set the metric and/or TE-metric proportional unprotected circuits and set the metric and/or TE-metric proportional
to latency. This resulted in traffic being directed over the least to latency. This resulted in traffic being directed over the least
latency path, even if this was not needed to meet an SLA or meet user latency path, even if this was not needed to meet an NPO or meet user
experience objectives. This results in reduced flexibility and experience objectives. This results in reduced flexibility and
increased cost for network operators. Using lower layer networks to increased cost for network operators. Using lower layer networks to
provide restoration and grooming is expected to be more efficient, provide restoration and grooming is expected to be more efficient,
but the inability to communicate performance parameters, in but the inability to communicate performance parameters, in
particular latency, from the lower layer network to the higher layer particular latency, from the lower layer network to the higher layer
network is an important problem to be solved before this can be done. network is an important problem to be solved before this can be done.
Latency SLAs for pt-pt services are often tied closely to geographic Latency NPOs for pt-pt services are often tied closely to geographic
locations, while latency for multipoint services may be based upon a locations, while latency for multipoint services may be based upon a
worst case within a region. worst case within a region.
Section 7 of [ITU-T.Y.1540] defines availability for an IP service in
terms of loss exceeding a threshold for a period on the order of 5
minutes. However, the timeframes for restoration (i.e., as
implemented by pre-determined protection, convergence of routing
protocols and/or signaling) for services range from on the order of
100 ms or less (e.g., for VPWS to emulate classical SDH/SONET
protection switching), to several minutes (e.g., to allow BGP to
reconverge for L3VPN) and may differ among the set of customers
within a single service.
The presence of only three Traffic Class (TC) bits (previously known The presence of only three Traffic Class (TC) bits (previously known
as EXP bits) in the MPLS shim header is limiting when a network as EXP bits) in the MPLS shim header is limiting when a network
operator needs to support QoS classes for multiple services (e.g., operator needs to support QoS classes for multiple services (e.g.,
L2VPN VPWS, VPLS, L3VPN and Internet), each of which has a set of QoS L2VPN VPWS, VPLS, L3VPN and Internet), each of which has a set of QoS
classes that need to be supported. In some cases one bit is used to classes that need to be supported. In some cases one bit is used to
indicate conformance to some ingress traffic classification, leaving indicate conformance to some ingress traffic classification, leaving
only two bits for indicating the service QoS classes. The approach only two bits for indicating the service QoS classes. The approach
that has been taken is to aggregate these QoS classes into similar that has been taken is to aggregate these QoS classes into similar
sets on LER-LSR and LSR-LSR links. sets on LER-LSR and LSR-LSR links.
 End of changes. 51 change blocks. 
120 lines changed or deleted 180 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/