draft-ietf-rtgwg-cl-requirement-15.txt   draft-ietf-rtgwg-cl-requirement-16.txt 
RTGWG C. Villamizar, Ed. RTGWG C. Villamizar, Ed.
Internet-Draft OCCNC, LLC Internet-Draft OCCNC, LLC
Intended status: Informational D. McDysan, Ed. Intended status: Informational D. McDysan, Ed.
Expires: July 29, 2014 Verizon Expires: August 10, 2014 Verizon
S. Ning S. Ning
Tata Communications Tata Communications
A. Malis A. Malis
Consultant Huawei
L. Yong L. Yong
Huawei USA Huawei USA
January 25, 2014 February 06, 2014
Requirements for Advanced Multipath in MPLS Networks Requirements for Advanced Multipath in MPLS Networks
draft-ietf-rtgwg-cl-requirement-15 draft-ietf-rtgwg-cl-requirement-16
Abstract Abstract
This document provides a set of requirements for Advanced Multipath This document provides a set of requirements for Advanced Multipath
in MPLS Networks. in MPLS Networks.
Advanced Multipath is a formalization of multipath techniques Advanced Multipath is a formalization of multipath techniques
currently in use in IP and MPLS networks and a set of extensions to currently in use in IP and MPLS networks and a set of extensions to
existing multipath techniques. existing multipath techniques.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 29, 2014. This Internet-Draft will expire on August 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 52 skipping to change at page 2, line 52
of core networks today far exceed the capacity of a single physical of core networks today far exceed the capacity of a single physical
link or single packet processing element. link or single packet processing element.
The presence of parallel links, with each link potentially comprised The presence of parallel links, with each link potentially comprised
of multiple layers has resulted in additional requirements. Certain of multiple layers has resulted in additional requirements. Certain
services may benefit from being restricted to a subset of the services may benefit from being restricted to a subset of the
component links or a specific component link, where component link component links or a specific component link, where component link
characteristics, such as latency, differ. Certain services require characteristics, such as latency, differ. Certain services require
that an 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 services will continue to require only that reordering not occur
within a microflow as is current practice. within a flow as is current practice.
Numerous forms of multipath exist today including MPLS Link Bundling Numerous forms of multipath exist today including MPLS Link Bundling
[RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and various [RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and various
forms of Equal Cost Multipath (ECMP) such as for OSPF ECMP, IS-IS forms of Equal Cost Multipath (ECMP) such as for OSPF ECMP, IS-IS
ECMP, and BGP ECMP. Refer to the Appendices in ECMP, and BGP ECMP. Refer to the Appendices in
[I-D.ietf-rtgwg-cl-use-cases] for a description of existing [I-D.ietf-rtgwg-cl-use-cases] for a description of existing
techniques and a set of references. techniques and a set of references.
The purpose of this document is to clearly enumerate a set of The purpose of this document is to clearly enumerate a set of
requirements related to the protocols and mechanisms that provide requirements related to the protocols and mechanisms that provide
MPLS based Advanced Multipath. The intent is to first provide a set MPLS based Advanced Multipath. The intent is to first provide a set
of functional requirements that are as independent as possible of of functional requirements, in Section 3, that are as independent as
protocol specifications in Section 3. A set of general protocol possible of protocol specifications . A set of general protocol
requirements are defined in Section 4. A set of network management requirements are defined in Section 4. A set of network management
requirements are defined in Section 5. requirements are defined in Section 5.
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].
Any statement which requires the solution to support some new Any statement which requires the solution to support some new
skipping to change at page 4, line 30 skipping to change at page 4, line 30
links where Advanced Multipath techniques are applied. links where Advanced Multipath techniques are applied.
Composite Link Composite Link
The term Composite Link had been a registered trademark of Avici The term Composite Link had been a registered trademark of Avici
Systems, but was abandoned in 2007. The term composite link is Systems, but was abandoned in 2007. The term composite link is
now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition
includes multipath as defined here, plus inverse multiplexing includes multipath as defined here, plus inverse multiplexing
which is explicitly excluded from the definition of multipath. which is explicitly excluded from the definition of multipath.
Inverse Multiplexing Inverse Multiplexing
Inverse multiplexing either transmits whole packets and Inverse multiplexing is another method of sending traffic over
resequences the packets at the receiving end or subdivides multiple links. Inverse multiplexing either transmits whole
packets and reassembles the packets at the receiving end. packets and resequences the packets at the receiving end or
Inverse multiplexing requires that all packets be handled by a subdivides packets and reassembles the packets at the receiving
common egress packet processing element and is therefore not end. Inverse multiplexing requires that all packets be handled
by a common egress packet processing element and is therefore not
useful for very high bandwidth applications. useful for very high bandwidth applications.
Component Link Component Link
The ITU-T definition of composite link in [ITU-T.G.800] and the The ITU-T definition of composite link in [ITU-T.G.800] and the
IETF definition of link bundling in [RFC4201] both refer to an IETF definition of link bundling in [RFC4201] both refer to an
individual link in the composite link or link bundle as a individual link in the composite link or link bundle as a
component link. The term component link is applicable to all component link. The term component link is applicable to all
forms of multipath. The IEEE uses the term member rather than forms of multipath. The IEEE uses the term member rather than
component link in Ethernet Link Aggregation [IEEE-802.1AX]. component link in Ethernet Link Aggregation [IEEE-802.1AX].
Client Layer Client Layer
A client layer is the one immediately above a server layer. A client layer is the layer immediately above a server layer.
Server Layer Server Layer
A server layer is the latey immediately below a client layer. A server layer is the layer immediately below a client layer.
Higher Layers Higher Layers
Relative to a particular layer, a client layer and any layer Relative to a particular layer, a client layer and any layer
above that is considered a higher layer. Upper layer is above that is considered a higher layer. Upper layer is
synonymous with higher layer. synonymous with higher layer.
Lower Layers Lower Layers
Relative to a particular layer, a server layer and any layer Relative to a particular layer, a server layer and any layer
below that is considered a lower layer. below that is considered a lower layer.
Client LSP Client LSP
A client LSP is an LSP which has been set up over one or more A client LSP is an LSP which has been set up over one or more
lower layers. In the context of this discussion, one type of lower layers. In the context of this discussion, one type of
client LSP is a LSP which has been set up over an AMG. client LSP is a LSP which has been set up over an AMG.
Flow Flow
A sequence of packets that should be transferred in order on one A sequence of packets that should be transferred in order on one
component link of a multipath. component link of a multipath.
Flow identification Flow Identification
The label stack and other information that uniquely identifies a The label stack and other information that uniquely identifies a
flow. Other information in flow identification may include an IP flow. Other information in flow identification may include an IP
header, pseudowire (PW) control word, Ethernet MAC address, etc. header, pseudowire (PW) control word, Ethernet MAC address, etc.
Note that a client LSP may contain one or more Flows or a client Note that a client LSP may contain one or more Flows or a client
LSP may be equivalent to a Flow. Flow identification is used to LSP may be equivalent to a Flow. Flow identification is used to
locally select a component link, or a path through the network locally select a component link, or a path through the network
toward the destination. toward the destination.
Load Balance Load Balance
Load split, load balance, or load distribution refers to Load split, load balance, or load distribution refers to
skipping to change at page 15, line 28 skipping to change at page 15, line 28
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-rtgwg-cl-framework] [I-D.ietf-rtgwg-cl-framework]
Ning, S., McDysan, D., Osborne, E., Yong, L., and C. Ning, S., McDysan, D., Osborne, E., Yong, L., and C.
Villamizar, "Composite Link Framework in Multi Protocol Villamizar, "Advanced Multipath Framework in MPLS", draft-
Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01 ietf-rtgwg-cl-framework-04 (work in progress), July 2013.
(work in progress), August 2012.
[I-D.ietf-rtgwg-cl-use-cases] [I-D.ietf-rtgwg-cl-use-cases]
Ning, S., Malis, A., McDysan, D., Yong, L., and C. Ning, S., Malis, A., McDysan, D., Yong, L., and C.
Villamizar, "Composite Link Use Cases and Design Villamizar, "Advanced Multipath Use Cases and Design
Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in Considerations", draft-ietf-rtgwg-cl-use-cases-05 (work in
progress), August 2012. progress), November 2013.
[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.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/
skipping to change at page 16, line 36 skipping to change at page 16, line 36
USA USA
Email: dave.mcdysan@verizon.com Email: dave.mcdysan@verizon.com
So Ning So Ning
Tata Communications Tata Communications
Email: ning.so@tatacommunications.com Email: ning.so@tatacommunications.com
Andrew Malis Andrew Malis
Consultant Huawei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
Lucy Yong Lucy Yong
Huawei USA Huawei USA
5340 Legacy Dr. 5340 Legacy Dr.
Plano, TX 75025 Plano, TX 75025
USA USA
Phone: +1 469-277-5837 Phone: +1 469-277-5837
 End of changes. 14 change blocks. 
23 lines changed or deleted 23 lines changed or added

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