< draft-fuxh-mpls-delay-loss-te-framework-02.txt   draft-fuxh-mpls-delay-loss-te-framework-03.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: April 10, 2012 Hewlett-Packard Corp. Expires: May 17, 2012 Hewlett-Packard Corp.
D. McDysan D. McDysan
A. Malis A. Malis
Verizon Verizon
S. Giacalone S. Giacalone
Thomson Reuters Thomson Reuters
M. Betts M. Betts
Q. Wang Q. Wang
ZTE ZTE
J. Drake J. Drake
Juniper Networks Juniper Networks
October 8, 2011 November 14, 2011
Traffic Engineering architecture for services aware MPLS Traffic Engineering architecture for services aware MPLS
draft-fuxh-mpls-delay-loss-te-framework-02 draft-fuxh-mpls-delay-loss-te-framework-03
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.
skipping to change at page 2, line 20 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 April 10, 2012. This Internet-Draft will expire on May 17, 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
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
2. Architecture requirements overview . . . . . . . . . . . . . . 4 2. Architecture requirements overview . . . . . . . . . . . . . . 4
2.1. Communicate Latency and Loss as TE Metric . . . . . . . . 4 2.1. Communicate Latency and Loss as TE Metric . . . . . . . . 4
2.2. Requirement for Composite Link . . . . . . . . . . . . . . 5 2.2. Requirement for Composite Link . . . . . . . . . . . . . . 5
2.3. Requirement for Hierarchy LSP . . . . . . . . . . . . . . 5 2.3. Requirement for Hierarchy LSP . . . . . . . . . . . . . . 5
2.4. Latency Accumulation and Verification . . . . . . . . . . 5 2.4. Latency Accumulation and Verification . . . . . . . . . . 5
2.5. Restoration, Protection and Rerouting . . . . . . . . . . 6 2.5. Restoration, Protection and Rerouting . . . . . . . . . . 6
3. End-to-End Latency . . . . . . . . . . . . . . . . . . . . . . 6 3. End-to-End Latency . . . . . . . . . . . . . . . . . . . . . . 6
4. End-to-End Jitter . . . . . . . . . . . . . . . . . . . . . . 7 4. End-to-End Jitter . . . . . . . . . . . . . . . . . . . . . . 8
5. End-to-End Loss . . . . . . . . . . . . . . . . . . . . . . . 8 5. End-to-End Loss . . . . . . . . . . . . . . . . . . . . . . . 8
6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 9
7. Control Plane Implication . . . . . . . . . . . . . . . . . . 9 7. Control Plane Implication . . . . . . . . . . . . . . . . . . 9
7.1. Implications for Routing . . . . . . . . . . . . . . . . . 9 7.1. Implications for Routing . . . . . . . . . . . . . . . . . 9
7.2. Implications for Signaling . . . . . . . . . . . . . . . . 10 7.2. Implications for Signaling . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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.
skipping to change at page 4, line 45 skipping to change at page 4, line 45
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 Latency, latency variation and packet loss may be unstable, for
example, if queueing latency were included, then IGP could become example, if queueing latency were included, then IGP could become
unstable. The solution MUST provide a means to control latency and unstable. The solution MUST provide a means to control latency and
loss IGP message advertisement and avoid unstable when the latency, loss IGP message advertisement and avoid unstable when the latency,
latency variation and packet loss value changes. latency variation and packet loss value changes.
In the case where it is known that either the changes are too
frequent or there is a backup which is preferred, we can put the node
or the link in unusable state for services requiring a particular
service capability. This unusable state is on a capability basis and
not a global basis.
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 less than Z% packet loss limit based on
latency and packet loss traffic engineering database. It MUST also the latency and packet loss traffic engineering database. It MUST
support the path computation with routing constraints combination also support the path computation with routing constraints
with pre-defined priorities, e.g., SRLG diversity, latency, loss and combination with pre-defined priorities, e.g., SRLG diversity,
cost. latency, loss, jitter and cost. If the performance of link exceeds
its configured maximum threshold, path computation entity may not
select this kind of link although end-to-end performance is still
met.
2.2. 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
skipping to change at page 6, line 11 skipping to change at page 6, line 19
scope of Network Operator policy than standards i.e. the operator scope of Network Operator policy than standards i.e. the operator
needs to decide, based on the SLAs offered, the required confidence needs to decide, based on the SLAs offered, the required confidence
level. level.
2.5. Restoration, Protection and Rerouting 2.5. Restoration, Protection and Rerouting
Some customers may insist on having the ability to re-route if the 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 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 LSP latency and/or loss could not meet the latency and loss agreement
between operator and his user, the solution SHOULD support pre- between operator and his user, the solution SHOULD support pre-
defined or dynamic re-routing to handle this case based on the local defined or dynamic re-routing (e.g., make-before-break) to handle
policy. this case based on the local policy. In revertive behaviour is
supported, the original LSP must not be released and is monitored by
control plane. When the end-to-end performance is repaired, the
service is restored to the original LSP.
The solution should support to move one end-to-end path away from any
link whose performance exceeds the configured maximum threshold. The
anomalous path can be switch to protection path or rerouted to new
path because of end-to-end performance couldn't meet any more.
If a "provisioned" end-to-end LSP latency and/or loss performance is If a "provisioned" end-to-end LSP latency and/or loss performance is
improved (i.e., beyond a configurable minimum value) because of some improved (i.e., beyond a configurable minimum value) because of some
segment performance promotion, the solution SHOULD support the re- segment performance promotion, the solution SHOULD support the re-
routing to optimize latency and/or loss end-to-end cost. routing to optimize latency and/or loss end-to-end cost.
The latency performance of pre-defined protection or dynamic re- The latency performance of pre-defined protection or dynamic re-
routing LSP MUST meet the latency SLA parameter. The difference of routing LSP MUST meet the latency SLA parameter. The difference of
latency value between primary and protection/restoration path SHOULD latency value between primary and protection/restoration path SHOULD
be zero. be zero.
skipping to change at page 10, line 7 skipping to change at page 10, line 22
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.
When the Composite Links [CL-REQ] is advertised into IGP, there are When the Composite Links [CL-REQ] is advertised into IGP, there are
following considerations. following considerations.
o One option is that the latency and packet loss of composite link 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 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. It may also be the maximum or
value of all component links. In both cases, only partial average latency value of all component links. In both cases, only
information is transmited in the IGP. So the path computation partial information is transmited in the IGP. So the path
entity has insufficient information to determine whether a computation entity has insufficient information to determine
particular path can support its latency and packet loss whether a particular path can support its latency and packet loss
requirements. This leads to signaling crankback. requirements. This leads to signaling crankback.
o Another option is that latency and packet loss of each component o Another option is that latency and packet loss of each component
link within one Composite Link could be advertised but having only link within one Composite Link could be advertised but having only
one IGP adjacency. one IGP adjacency.
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
a FA-LSP of server layer (e.g., OTN rings). The boundary nodes of 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 the FA-LSP SHOULD be aware of the latency and packet loss information
of this FA-LSP. of this FA-LSP.
 End of changes. 12 change blocks. 
20 lines changed or deleted 37 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/