< draft-fuxh-mpls-delay-loss-te-framework-01.txt   draft-fuxh-mpls-delay-loss-te-framework-02.txt >
Network Working Group X. Fu Network Working Group X. Fu
Internet-Draft ZTE Internet-Draft ZTE
Intended status: Standards Track V. Manral Intended status: Standards Track V. Manral
Expires: March 15, 2012 Hewlett-Packard Corp. Expires: April 10, 2012 Hewlett-Packard Corp.
D. McDysan
A. Malis
Verizon
S. Giacalone S. Giacalone
Thomson Reuters Thomson Reuters
M. Betts M. Betts
Q. Wang Q. Wang
ZTE ZTE
D. McDysan
A. Malis
Verizon
J. Drake J. Drake
Juniper Networks Juniper Networks
September 12, 2011 October 8, 2011
Traffic Engineering architecture for services aware MPLS Traffic Engineering architecture for services aware MPLS
draft-fuxh-mpls-delay-loss-te-framework-01 draft-fuxh-mpls-delay-loss-te-framework-02
Abstract Abstract
With more and more enterprises using cloud based services, the With more and more enterprises using cloud based services, the
distances between the user and the applications are growing. A lot distances between the user and the applications are growing. A lot
of the current applications are designed to work across LAN's and of the current applications are designed to work across LAN's and
have various inherent assumptions. For multiple applications such as have various inherent assumptions. For multiple applications such as
High Performance Computing and Electronic Financial markets, the High Performance Computing and Electronic Financial markets, the
response times are critical as is packet loss, while other response times are critical as is packet loss, while other
applications require more throughput. applications require more throughput.
[RFC3031] describes the architecture of MPLS based networks. This [RFC3031] describes the architecture of MPLS based networks. This
draft extends the MPLS architecture to allow for latency, loss and draft extends the MPLS architecture to allow for latency, loss and
jitter as properties. jitter as properties. It describes requirements and control plane
implication for latency and packet loss as a traffic engineering
performance metric in today's network which is consisting of
potentially multiple layers of packet transport network and optical
transport network in order to make a accurate end-to-end latency and
loss prediction before a path is established.
Note MPLS architecture for Multicast will be taken up in a future Note MPLS architecture for Multicast will be taken up in a future
version of the draft. version of the draft.
Requirements Language 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]. document are to be interpreted as described in [RFC 2119].
skipping to change at page 2, line 15 skipping to change at page 2, line 20
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 March 15, 2012. This Internet-Draft will expire on April 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture requirements overview . . . . . . . . . . . . . . 4 2. Architecture requirements overview . . . . . . . . . . . . . . 4
2.1. Requirement for Composite Link . . . . . . . . . . . . . . 4 2.1. Communicate Latency and Loss as TE Metric . . . . . . . . 4
2.2. Requirement for Hierarchy LSP . . . . . . . . . . . . . . 5 2.2. Requirement for Composite Link . . . . . . . . . . . . . . 5
3. End-to-End Latency Measurements . . . . . . . . . . . . . . . 5 2.3. Requirement for Hierarchy LSP . . . . . . . . . . . . . . 5
4. End-to-End Jitter Measurements . . . . . . . . . . . . . . . . 6 2.4. Latency Accumulation and Verification . . . . . . . . . . 5
5. End-to-End Loss Measurements . . . . . . . . . . . . . . . . . 7 2.5. Restoration, Protection and Rerouting . . . . . . . . . . 6
6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7 3. End-to-End Latency . . . . . . . . . . . . . . . . . . . . . . 6
7. Restoration, Protection and Rerouting . . . . . . . . . . . . 8 4. End-to-End Jitter . . . . . . . . . . . . . . . . . . . . . . 7
8. Control Plane Implication . . . . . . . . . . . . . . . . . . 8 5. End-to-End Loss . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Implications for Routing . . . . . . . . . . . . . . . . . 8 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8
8.1.1. Implications for Signaling . . . . . . . . . . . . . . 9 7. Control Plane Implication . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.1. Implications for Routing . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.2. Implications for Signaling . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
In High Frequency trading for Electronic Financial markets, computers In High Frequency trading for Electronic Financial markets, computers
make decisions based on the Electronic Data received, without human make decisions based on the Electronic Data received, without human
intervention. These trades now account for a majority of the trading intervention. These trades now account for a majority of the trading
volumes and rely exclusively on ultra-low-latency direct market volumes and rely exclusively on ultra-low-latency direct market
access. access.
Extremely low latency measurements for MPLS LSP tunnels are defined Extremely low latency measurements for MPLS LSP tunnels are defined
skipping to change at page 4, line 33 skipping to change at page 4, line 33
or jitter characteristics. or jitter characteristics.
End-to-end service optimization based on latency and packet loss is a End-to-end service optimization based on latency and packet loss is a
key requirement for service provider. This type of function will be key requirement for service provider. This type of function will be
adopted by their "premium" service customers. They would like to pay adopted by their "premium" service customers. They would like to pay
for this "premium" service. Latency and loss on a route level will for this "premium" service. Latency and loss on a route level will
help carriers' customers to make his provider selection decision. help carriers' customers to make his provider selection decision.
2. Architecture requirements overview 2. Architecture requirements overview
2.1. Communicate Latency and Loss as TE Metric
The solution MUST provide a means to communicate latency, latency The solution MUST provide a means to communicate latency, latency
variation and packet loss of links and nodes as a traffic engineering variation and packet loss of links and nodes as a traffic engineering
performance metric into IGP. performance metric into IGP.
Latency, latency variation and packet loss may be unstable, for
example, if queueing latency were included, then IGP could become
unstable. The solution MUST provide a means to control latency and
loss IGP message advertisement and avoid unstable when the latency,
latency variation and packet loss value changes.
Path computation entity MUST have the capability to compute one end- Path computation entity MUST have the capability to compute one end-
to-end path with latency and packet loss constraint. For example, it to-end path with latency and packet loss constraint. For example, it
has the capability to compute a route with X amount of bandwidth with has the capability to compute a route with X amount of bandwidth with
less than Y ms of latency and Z% packet loss limit based on the less than Y ms of latency and Z% packet loss limit based on the
latency and packet loss traffic engineering database. It MUST also latency and packet loss traffic engineering database. It MUST also
support the path computation with routing constraints combination support the path computation with routing constraints combination
with pre-defined priorities, e.g., SRLG diversity, latency, loss and with pre-defined priorities, e.g., SRLG diversity, latency, loss and
cost. cost.
2.1. Requirement for Composite Link 2.2. Requirement for Composite Link
One end-to-end LSP may traverses some Composite Links [CL-REQ]. Even One end-to-end LSP may traverses some Composite Links [CL-REQ]. Even
if the transport technology (e.g., OTN) component links are if the transport technology (e.g., OTN) component links are
identical, the latency and packet loss characteristics of the identical, the latency and packet loss characteristics of the
component links may differ. component links may differ.
The solution MUST provide a means to indicate that a traffic flow The solution MUST provide a means to indicate that a traffic flow
should select a component link with minimum latency and/or packet should select a component link with minimum latency and/or packet
loss, maximum acceptable latency and/or packet loss value and maximum loss, maximum acceptable latency and/or packet loss value and maximum
acceptable delay variation value as specified by protocol. The acceptable delay variation value as specified by protocol. The
endpoints of Composite Link will take these parameters into account endpoints of Composite Link will take these parameters into account
for component link selection or creation. The exact details for for component link selection or creation. The exact details for
component links will be taken up seperately and are not part of this component links will be taken up seperately and are not part of this
document. document.
2.2. Requirement for Hierarchy LSP 2.3. Requirement for Hierarchy LSP
One end-to-end LSP may traverse a server layer. There will be some One end-to-end LSP may traverse a server layer. There will be some
latency and packet loss constraint requirement for the segment route latency and packet loss constraint requirement for the segment route
in server layer. in server layer.
The solution MUST provide a means to indicate FA selection or FA-LSP The solution MUST provide a means to indicate FA selection or FA-LSP
creation with minimum latency and/or packet loss, maximum acceptable creation with minimum latency and/or packet loss, maximum acceptable
latency and/or packet loss value and maximum acceptable delay latency and/or packet loss value and maximum acceptable delay
variation value. The boundary nodes of FA-LSP will take these variation value. The boundary nodes of FA-LSP will take these
parameters into account for FA selection or FA-LSP creation. parameters into account for FA selection or FA-LSP creation.
3. End-to-End Latency Measurements 2.4. Latency Accumulation and Verification
The solution SHOULD provide a means to accumulate (e.g., sum) of
latency information of links and nodes along one LSP across multi-
domain (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency
validation decision can be made at the source node. One-way and
round-trip latency collection along the LSP by signaling protocol and
latency verification at the end of LSP should be supported.
The accumulation of the delay is "simple" for the static component
i.e. its a linear addition, the dynamic/network loading component is
more interesting and would involve some estimate of the "worst case".
However, method of deriving this worst case appears to be more in the
scope of Network Operator policy than standards i.e. the operator
needs to decide, based on the SLAs offered, the required confidence
level.
2.5. Restoration, Protection and Rerouting
Some customers may insist on having the ability to re-route if the
latency and loss SLA is not being met. If a "provisioned" end-to-end
LSP latency and/or loss could not meet the latency and loss agreement
between operator and his user, the solution SHOULD support pre-
defined or dynamic re-routing to handle this case based on the local
policy.
If a "provisioned" end-to-end LSP latency and/or loss performance is
improved (i.e., beyond a configurable minimum value) because of some
segment performance promotion, the solution SHOULD support the re-
routing to optimize latency and/or loss end-to-end cost.
The latency performance of pre-defined protection or dynamic re-
routing LSP MUST meet the latency SLA parameter. The difference of
latency value between primary and protection/restoration path SHOULD
be zero.
As a result of the change of latency and loss in the LSP, current LSP
may be frequently switched to a new LSP with a appropriate latency
and packet loss value. In order to avoid this, the solution SHOULD
indicate the switchover of the LSP according to maximum acceptable
change latency and packet loss value.
3. End-to-End Latency
Procedures to measure latency and loss has been provided in ITU-T Procedures to measure latency and loss has been provided in ITU-T
[Y.1731], [G.709] and [ietf-mpls-loss-delay]. The control plane can [Y.1731], [G.709] and [ietf-mpls-loss-delay]. The control plane can
is independent of the mechanism used and different mechanisms can be be independent of the mechanism used and different mechanisms can be
used for measurement based on different standards. used for measurement based on different standards.
Latency on a path has two sources: Node latency which is caused by Latency on a path has two sources: Node latency which is caused by
the node as a result of process time in each node and: Link latency the node as a result of process time in each node and: Link latency
as a result of packet/frame transit time between two neighbouring as a result of packet/frame transit time between two neighbouring
nodes or a FA-LSP/ Composite Link [CL-REQ]. nodes or a FA-LSP/ Composite Link [CL-REQ].
Latency or one-way delay is the time it takes for a packet within a Latency or one-way delay is the time it takes for a packet within a
stream going from measurement point 1 to measurement point 2. stream going from measurement point 1 to measurement point 2.
skipping to change at page 6, line 29 skipping to change at page 7, line 33
Another approximation that can be used is per interface DSCP based Another approximation that can be used is per interface DSCP based
measurement, which can be an agrregate of the average measurements measurement, which can be an agrregate of the average measurements
per interface. The average can itself be calculated in ways, so as per interface. The average can itself be calculated in ways, so as
to provide closer approximation. to provide closer approximation.
For the purpose of this draft it is assumed that the node latency is For the purpose of this draft it is assumed that the node latency is
a small factor of the total latency in the networks where this a small factor of the total latency in the networks where this
solution is deployed. The node latency is hence ignored for the solution is deployed. The node latency is hence ignored for the
benefit of simplicity. benefit of simplicity.
The delay is measured in terms of 10's of nano-seconds. The average link delay over a configurable interval should be
reported by data plane in micro-seconds.
4. End-to-End Jitter Measurements 4. End-to-End Jitter
Jitter or Packet Delay Variation of a packet within a stream of Jitter or Packet Delay Variation of a packet within a stream of
packets is defined for a selected pair of packets in the stream going packets is defined for a selected pair of packets in the stream going
from measurement point 1 to measurement point 2. from measurement point 1 to measurement point 2.
The architecture uses assumption that the sum of the jitter of the The architecture uses assumption that the sum of the jitter of the
individual components approximately adds up to the average jitter of individual components approximately adds up to the average jitter of
an LSP. Though using the sum may not be perfect, it however gives a an LSP. Though using the sum may not be perfect, it however gives a
good approximation that can be used for Traffic Engineering (TE) good approximation that can be used for Traffic Engineering (TE)
purposes. purposes.
skipping to change at page 6, line 46 skipping to change at page 8, line 4
The architecture uses assumption that the sum of the jitter of the The architecture uses assumption that the sum of the jitter of the
individual components approximately adds up to the average jitter of individual components approximately adds up to the average jitter of
an LSP. Though using the sum may not be perfect, it however gives a an LSP. Though using the sum may not be perfect, it however gives a
good approximation that can be used for Traffic Engineering (TE) good approximation that can be used for Traffic Engineering (TE)
purposes. purposes.
There may be very less jitter on a link-hop basis. There may be very less jitter on a link-hop basis.
The buffering and queuing within a device will lead to the jitter. The buffering and queuing within a device will lead to the jitter.
Just like latency measurements, jitter measurements can be Just like latency measurements, jitter measurements can be
appproximated as either per DSCP per port pair (Ingresss and Egress) appproximated as either per DSCP per port pair (Ingresss and Egress)
or as per DSCP per egress port. or as per DSCP per egress port.
For the purpose of this draft it is assumed that the node latency is For the purpose of this draft it is assumed that the node latency is
a small factor of the total latency in the networks where this a small factor of the total latency in the networks where this
solution is deployed. The node latency is hence ignored for the solution is deployed. The node latency is hence ignored for the
benefit of simplicity. benefit of simplicity.
The jitter is measured in terms of 10's of nano-seconds. The jitter is measured in terms of 10's of nano-seconds.
5. End-to-End Loss Measurements 5. End-to-End Loss
Loss or Packet Drop probability of a packet within a stream of Loss or Packet Drop probability of a packet within a stream of
packets is defined as the number of packets dropped within a given packets is defined as the number of packets dropped within a given
interval. interval.
The architecture uses assumption that the sum of the loss of the The architecture uses assumption that the sum of the loss of the
individual components approximately adds up to the average loss of an individual components approximately adds up to the average loss of an
LSP. Though using the sum may not be perfect, it however gives a LSP. Though using the sum may not be perfect, it however gives a
good approximation that can be used for Traffic Engineering (TE) good approximation that can be used for Traffic Engineering (TE)
purposes. purposes.
skipping to change at page 7, line 36 skipping to change at page 8, line 42
which packet is to be dropped. Just like latency and jitter which packet is to be dropped. Just like latency and jitter
measurements, the loss can best be appproximated as either per DSCP measurements, the loss can best be appproximated as either per DSCP
per port pair (Ingresss and Egress) or as per DSCP per egress port. per port pair (Ingresss and Egress) or as per DSCP per egress port.
The loss is measured in terms of the number of packets per million The loss is measured in terms of the number of packets per million
packets. packets.
6. Protocol Considerations 6. Protocol Considerations
The protocol metrics above can be sent in IGP protocol packets RFC The protocol metrics above can be sent in IGP protocol packets RFC
3630. They can then be used by the Path Computation engine to 3630. They can then be used by the Path Computation engine to decide
dervice paths with the desired path properties. paths with the desired path properties.
As Link-state IGP information is flooded throughout an area, frequent As Link-state IGP information is flooded throughout an area, frequent
changes can cause a lot of control traffic. To prevent such changes can cause a lot of control traffic. To prevent such
flooding, data should only be flooded when it crosses a certain flooding, data should only be flooded when it crosses a certain
configured maximum. configured maximum.
A seperate measurement should be done for an LSP when it is UP. Also A seperate measurement should be done for an LSP when it is UP. Also
LSP's path should only be recalculated when the end-to-end metrics LSP's path should only be recalculated when the end-to-end metrics
changes in a way it becomes more then desired. changes in a way it becomes more than desired.
7. Restoration, Protection and Rerouting
Some customers may insist on having the ability to re-route if the
latency and loss SLA is not being met. If a "provisioned" end-to-end
LSP latency and/or loss could not meet the latency and loss agreement
between operator and his user, the solution SHOULD support pre-
defined or dynamic re-routing to handle this case based on the local
policy.
If a "provisioned" end-to-end LSP latency and/or loss performance is
improved (i.e., beyond a configurable minimum value) because of some
segment performance promotion, the solution SHOULD support the re-
routing to optimize latency and/or loss end-to-end cost.
The latency performance of pre-defined protection or dynamic re-
routing LSP MUST meet the latency SLA parameter. The difference of
latency value between primary and protection/restoration path SHOULD
be zero.
As a result of the change of latency and loss in the LSP, current LSP
may be frequently switched to a new LSP with a appropriate latency
and packet loss value. In order to avoid this, the solution SHOULD
indicate the switchover of the LSP according to maximum acceptable
change latency and packet loss value.
8. Control Plane Implication 7. Control Plane Implication
8.1. Implications for Routing 7.1. Implications for Routing
The latency and packet loss performance metric MUST be advertised The latency and packet loss performance metric MUST be advertised
into path computation entity by IGP (etc., OSPF-TE or IS-IS-TE) to into path computation entity by IGP (etc., OSPF-TE or IS-IS-TE) to
perform route computation and network planning based on latency and perform route computation and network planning based on latency and
packet loss SLA target. packet loss SLA target.
Latency, latecny variation and packet loss value MUST be reported as Latency, latecny variation and packet loss value MUST be reported as
a average value which is calculated by data plane. a average value which is calculated by data plane.
Latency and packet loss characteristics of these links and nodes may Latency and packet loss characteristics of these links and nodes may
skipping to change at page 9, line 24 skipping to change at page 9, line 49
avoid nodes that have a significant contribution to latency. Control avoid nodes that have a significant contribution to latency. Control
plane should report two components of the delay, "static" and plane should report two components of the delay, "static" and
"dynamic". The dynamic component is always caused by traffic loading "dynamic". The dynamic component is always caused by traffic loading
and queuing. The "dynamic" portion SHOULD be reported as an and queuing. The "dynamic" portion SHOULD be reported as an
approximate value. It should be a fixed latency through the node approximate value. It should be a fixed latency through the node
without any queuing. Link latency attribute should also take into without any queuing. Link latency attribute should also take into
account the latency of node, i.e., the latency between the incoming account the latency of node, i.e., the latency between the incoming
port and the outgoing port of a network element. Half of the fixed port and the outgoing port of a network element. Half of the fixed
node latency can be added to each link. node latency can be added to each link.
8.1.1. Implications for Signaling When the Composite Links [CL-REQ] is advertised into IGP, there are
following considerations.
o One option is that the latency and packet loss of composite link
may be the range (e.g., at least minimum and maximum) latency
value of all component links. It may also be the maximum latency
value of all component links. In both cases, only partial
information is transmited in the IGP. So the path computation
entity has insufficient information to determine whether a
particular path can support its latency and packet loss
requirements. This leads to signaling crankback.
o Another option is that latency and packet loss of each component
link within one Composite Link could be advertised but having only
one IGP adjacency.
One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse
a FA-LSP of server layer (e.g., OTN rings). The boundary nodes of
the FA-LSP SHOULD be aware of the latency and packet loss information
of this FA-LSP.
If the FA-LSP is able to form a routing adjacency and/or as a TE link
in the client network, the total latency and packet loss value of the
FA-LSP can be as an input to a transformation that results in a FA
traffic engineering metric and advertised into the client layer
routing instances. Note that this metric will include the latency
and packet loss of the links and nodes that the trail traverses.
If total latency and packet loss information of the FA-LSP changes
(e.g., due to a maintenance action or failure in OTN rings), the
boundary node of the FA-LSP will receive the TE link information
advertisement including the latency and packet value which is already
changed and if it is over than the threshold and a limit on rate of
change, then it will compute the total latency and packet value of
the FA-LSP again. If the total latency and packet loss value of FA-
LSP changes, the client layer MUST also be notified about the latest
value of FA. The client layer can then decide if it will accept the
increased latency and packet loss or request a new path that meets
the latency and packet loss requirement.
7.2. Implications for Signaling
In order to assign the LSP to one of component links with different In order to assign the LSP to one of component links with different
latency and loss characteristics, RSVP-TE message needs to carry a latency and loss characteristics, RSVP-TE message needs to carry a
indication of request minimum latency and/or packet loss, maximum indication of request minimum latency and/or packet loss, maximum
acceptable latency and/or packet loss value and maximum acceptable acceptable latency and/or packet loss value and maximum acceptable
delay variation value for the component link selection or creation. delay variation value for the component link selection or creation.
The composite link will take these parameters into account when The composite link will take these parameters into account when
assigning traffic of LSP to a component link. assigning traffic of LSP to a component link.
One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse
skipping to change at page 10, line 32 skipping to change at page 12, line 5
of pre-defined restoration for this transfer, but they have to of pre-defined restoration for this transfer, but they have to
duplicate restoration resources at significant cost. Solution should duplicate restoration resources at significant cost. Solution should
provides some mechanisms to avoid the duplicate restoration and provides some mechanisms to avoid the duplicate restoration and
reduce the network cost. Dynamic re-routing also has to face the reduce the network cost. Dynamic re-routing also has to face the
risk of resource limitation. So the choice of mechanism MUST be risk of resource limitation. So the choice of mechanism MUST be
based on SLA or policy. In the case where the latency SLA can not be based on SLA or policy. In the case where the latency SLA can not be
met after a re-route is attempted, control plane should report an met after a re-route is attempted, control plane should report an
alarm to management plane. It could also try restoration for several alarm to management plane. It could also try restoration for several
times which could be configured. times which could be configured.
9. IANA Considerations 8. IANA Considerations
No new IANA consideration are raised by this document. No new IANA consideration are raised by this document.
10. Security Considerations 9. Security Considerations
This document raises no new security issues. This document raises no new security issues.
11. Acknowledgements 10. Acknowledgements
TBD. TBD.
12. References 11. References
12.1. Normative References 11.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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
skipping to change at page 11, line 32 skipping to change at page 12, line 44
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. September 2003.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)", of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005. RFC 4203, October 2005.
7.2. Informative References 11.2. Informative References
[CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite [CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite
Link", draft-ietf-rtgwg-cl-requirement-02 . Link", draft-ietf-rtgwg-cl-requirement-04 .
[EXPRESS-PATH]
S. Giacalone, "OSPF Traffic Engineering (TE) Express
Path", draft-giacalone-ospf-te-express-path-01 .
[G.709] ITU-T Recommendation G.709, "Interfaces for the Optical [G.709] ITU-T Recommendation G.709, "Interfaces for the Optical
Transport Network (OTN)", December 2009. Transport Network (OTN)", December 2009.
[Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms [Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms
for Ethernet based networks", Feb 2008. for Ethernet based networks", Feb 2008.
[ietf-mpls-loss-delay] [ietf-mpls-loss-delay]
D. Frost, "Packet Loss and Delay Measurement for MPLS D. Frost, "Packet Loss and Delay Measurement for MPLS
Networks", draft-ietf-mpls-loss-delay-03 . Networks", draft-ietf-mpls-loss-delay-03 .
skipping to change at page 12, line 22 skipping to change at page 13, line 34
Vishwas Manral Vishwas Manral
Hewlett-Packard Corp. Hewlett-Packard Corp.
191111 Pruneridge Ave. 191111 Pruneridge Ave.
Cupertino, CA 95014 Cupertino, CA 95014
US US
Phone: 408-447-1497 Phone: 408-447-1497
Email: vishwas.manral@hp.com Email: vishwas.manral@hp.com
URI: URI:
Dave McDysan
Verizon
Email: dave.mcdysan@verizon.com
Andrew Malis
Verizon
Email: andrew.g.malis@verizon.com
Spencer Giacalone Spencer Giacalone
Thomson Reuters Thomson Reuters
195 Broadway 195 Broadway
New York, NY 10007 New York, NY 10007
US US
Phone: 646-822-3000 Phone: 646-822-3000
Email: spencer.giacalone@thomsonreuters.com Email: spencer.giacalone@thomsonreuters.com
URI: URI:
Malcolm Betts Malcolm Betts
ZTE ZTE
Email: malcolm.betts@zte.com.cn Email: malcolm.betts@zte.com.cn
Qilei Wang Qilei Wang
ZTE ZTE
Email: wang.qilei@zte.com.cn Email: wang.qilei@zte.com.cn
Dave McDysan
Verizon
Email: dave.mcdysan@verizon.com
Andrew Malis
Verizon
Email: andrew.g.malis@verizon.com
John Drake John Drake
Juniper Networks Juniper Networks
Email: jdrake@juniper.net Email: jdrake@juniper.net
 End of changes. 31 change blocks. 
76 lines changed or deleted 157 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/