draft-ietf-rtgwg-cl-framework-00.txt   draft-ietf-rtgwg-cl-framework-01.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
E. Osborne E. Osborne
Cisco Cisco
L. Yong L. Yong
Huawei USA Huawei USA
C. Villamizar C. Villamizar
Outer Cape Cod Network Outer Cape Cod Network
Consulting Consulting
August 12, 2012 August 12, 2012
Composite Link Framework in Multi Protocol Label Switching (MPLS) Composite Link Framework in Multi Protocol Label Switching (MPLS)
draft-ietf-rtgwg-cl-framework-00 draft-ietf-rtgwg-cl-framework-01
Abstract Abstract
This document specifies a framework for support of composite link in This document specifies a framework for support of composite link in
MPLS networks. A composite link consists of a group of homogenous or MPLS networks. A composite link consists of a group of homogenous or
non-homogenous links that have the same forward adjacency and can be non-homogenous links that have the same forward adjacency and can be
considered as a single TE link or an IP link in routing. A composite considered as a single TE link or an IP link in routing. A composite
link relies on its component links to carry the traffic over the link relies on its component links to carry the traffic over the
composite link. Applicability is described for a single pair of composite link. Applicability is described for a single pair of
MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of
skipping to change at page 3, line 36 skipping to change at page 3, line 36
7.2.14. Multi-Domain Composite Link . . . . . . . . . . . . . 33 7.2.14. Multi-Domain Composite Link . . . . . . . . . . . . . 33
7.3. Open Issues Regarding Requirements . . . . . . . . . . . . 34 7.3. Open Issues Regarding Requirements . . . . . . . . . . . . 34
7.4. Framework Requirement Coverage by Protocol . . . . . . . . 34 7.4. Framework Requirement Coverage by Protocol . . . . . . . . 34
7.4.1. OSPF-TE and ISIS-TE Protocol Extensions . . . . . . . 35 7.4.1. OSPF-TE and ISIS-TE Protocol Extensions . . . . . . . 35
7.4.2. PW Protocol Extensions . . . . . . . . . . . . . . . . 35 7.4.2. PW Protocol Extensions . . . . . . . . . . . . . . . . 35
7.4.3. LDP Protocol Extensions . . . . . . . . . . . . . . . 35 7.4.3. LDP Protocol Extensions . . . . . . . . . . . . . . . 35
7.4.4. RSVP-TE Protocol Extensions . . . . . . . . . . . . . 35 7.4.4. RSVP-TE Protocol Extensions . . . . . . . . . . . . . 35
7.4.5. RSVP-TE Path Selection Changes . . . . . . . . . . . . 35 7.4.5. RSVP-TE Path Selection Changes . . . . . . . . . . . . 35
7.4.6. RSVP-TE Admission Control and Preemption . . . . . . . 35 7.4.6. RSVP-TE Admission Control and Preemption . . . . . . . 35
7.4.7. Flow Identification and Traffic Balance . . . . . . . 35 7.4.7. Flow Identification and Traffic Balance . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . . 37 11.1. Normative References . . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Composite Link functional requirements are specified in Composite Link functional requirements are specified in
[I-D.ietf-rtgwg-cl-requirement]. Composite Link use cases are [I-D.ietf-rtgwg-cl-requirement]. Composite Link use cases are
described in [I-D.symmvo-rtgwg-cl-use-cases]. This document described in [I-D.ietf-rtgwg-cl-use-cases]. This document specifies
specifies a framework to meet these requirements. a framework to meet these requirements.
Classic multipath, including Ethernet Link Aggregation has been Classic multipath, including Ethernet Link Aggregation has been
widely used in today's MPLS networks [RFC4385][RFC4928]. Classic widely used in today's MPLS networks [RFC4385][RFC4928]. Classic
multipath using non-Ethernet links are often advertised using MPLS multipath using non-Ethernet links are often advertised using MPLS
Link bundling. A link bundle [RFC4201] bundles a group of Link bundling. A link bundle [RFC4201] bundles a group of
homogeneous links as a TE link to make IGP-TE information exchange homogeneous links as a TE link to make IGP-TE information exchange
and RSVP-TE signaling more scalable. A composite link allows and RSVP-TE signaling more scalable. A composite link allows
bundling non-homogenous links together as a single logical link. The bundling non-homogenous links together as a single logical link. The
motivations for using a composite link are descried in motivations for using a composite link are descried in
[I-D.ietf-rtgwg-cl-requirement] and [I-D.symmvo-rtgwg-cl-use-cases]. [I-D.ietf-rtgwg-cl-requirement] and [I-D.ietf-rtgwg-cl-use-cases].
This document describes a composite link framework in the context of This document describes a composite link framework in the context of
MPLS networks using an IGP-TE and RSVP-TE MPLS control plane with MPLS networks using an IGP-TE and RSVP-TE MPLS control plane with
GMPLS extensions [RFC3209][RFC3630][RFC3945][RFC5305]. GMPLS extensions [RFC3209][RFC3630][RFC3945][RFC5305].
A composite link is a single logical link in MPLS network that A composite link is a single logical link in MPLS network that
contains multiple parallel component links between two MPLS LSR. contains multiple parallel component links between two MPLS LSR.
Unlike a link bundle [RFC4201], the component links in a composite Unlike a link bundle [RFC4201], the component links in a composite
link can have different properties such as cost or capacity. link can have different properties such as cost or capacity.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
when the entire label stack is used and is always the case when IP when the entire label stack is used and is always the case when IP
addresses are used in provider networks carrying Internet traffic. addresses are used in provider networks carrying Internet traffic.
Current practice for native IP load balancing at the time of writing Current practice for native IP load balancing at the time of writing
were documented in [RFC2991], [RFC2992]. These practices as were documented in [RFC2991], [RFC2992]. These practices as
described, make use of IP addresses. The common practices were described, make use of IP addresses. The common practices were
extended to include the MPLS label stack and the common practice of extended to include the MPLS label stack and the common practice of
looking at IP addresses within the MPLS payload. These extended looking at IP addresses within the MPLS payload. These extended
practices are described in [RFC4385] and [RFC4928] due to their practices are described in [RFC4385] and [RFC4928] due to their
impact on pseudowires without a PWE3 Control Word. Additional detail impact on pseudowires without a PWE3 Control Word. Additional detail
on current multipath practices can be found in the appendices of on current multipath practices can be found in the appendices of
[I-D.symmvo-rtgwg-cl-use-cases]. [I-D.ietf-rtgwg-cl-use-cases].
Using only the top label supports too coarse a traffic balance. Using only the top label supports too coarse a traffic balance.
Using the full label stack or IP addresses as flow identification Using the full label stack or IP addresses as flow identification
provides a sufficiently fine traffic balance, but is capable of provides a sufficiently fine traffic balance, but is capable of
identifying such a high number of distinct flows, that a technique of identifying such a high number of distinct flows, that a technique of
grouping flows, such as hashing on the flow identification criteria, grouping flows, such as hashing on the flow identification criteria,
becomes essential to reduce the stored state, and is an essential becomes essential to reduce the stored state, and is an essential
scaling technique. Other means of grouping flows may be possible. scaling technique. Other means of grouping flows may be possible.
In summary: In summary:
skipping to change at page 24, line 7 skipping to change at page 24, line 7
needs to be extended to reflect new constraints based on the needs to be extended to reflect new constraints based on the
extended attributes. extended attributes.
5. Dynamic load balance must be provided for flows within a given 5. Dynamic load balance must be provided for flows within a given
set of links with common attributes such that NPO are not set of links with common attributes such that NPO are not
violated including frequency of load balance adjustment for any violated including frequency of load balance adjustment for any
given flow. given flow.
5.2. Classic Multipath 5.2. Classic Multipath
Classic multipath is defined in [I-D.symmvo-rtgwg-cl-use-cases]. Classic multipath is defined in [I-D.ietf-rtgwg-cl-use-cases].
Classic multipath refers to the most common current practice in Classic multipath refers to the most common current practice in
implementation and deployment of multipath. The most common current implementation and deployment of multipath. The most common current
practice makes use of a hash on the MPLS label stack and if IPv4 or practice makes use of a hash on the MPLS label stack and if IPv4 or
IPv6 are indicated under the label stack, makes use of the IP source IPv6 are indicated under the label stack, makes use of the IP source
and destination addresses [RFC4385] [RFC4928]. and destination addresses [RFC4385] [RFC4928].
Classic multipath provides a highly scalable means of load balancing. Classic multipath provides a highly scalable means of load balancing.
Adaptive multipath has proven value in assuring an even loading on Adaptive multipath has proven value in assuring an even loading on
component link and an ability to adapt to change in offerred load component link and an ability to adapt to change in offerred load
skipping to change at page 24, line 29 skipping to change at page 24, line 29
Classic multipath scalability is due to the ability to effectively Classic multipath scalability is due to the ability to effectively
work with an extremely large number of flows (IP host pairs) using work with an extremely large number of flows (IP host pairs) using
relatively little resources (a data structure accessed using a hash relatively little resources (a data structure accessed using a hash
result as a key or using ranges of hash results). result as a key or using ranges of hash results).
Classic multipath meets a small subset of Composite Link Classic multipath meets a small subset of Composite Link
requirements. Due to scalability of the approach, classic multipath requirements. Due to scalability of the approach, classic multipath
seems to be an excellent candidate for extension to meet the full set seems to be an excellent candidate for extension to meet the full set
of Composite Link forwarding requirements. of Composite Link forwarding requirements.
Additional detail can be found in [I-D.symmvo-rtgwg-cl-use-cases]. Additional detail can be found in [I-D.ietf-rtgwg-cl-use-cases].
6. Mechanisms Proposed in Other Documents 6. Mechanisms Proposed in Other Documents
A number of documents which at the time of writing are works in A number of documents which at the time of writing are works in
progress address parts of the requirements of Composite Link, or progress address parts of the requirements of Composite Link, or
assist in making some of the goals achievable. assist in making some of the goals achievable.
6.1. Loss and Delay Measurement 6.1. Loss and Delay Measurement
Procedures for measuring loss and delay are provided in [RFC6374]. Procedures for measuring loss and delay are provided in [RFC6374].
skipping to change at page 35, line 49 skipping to change at page 35, line 49
resource changes such as a link delay change might trigger resource changes such as a link delay change might trigger
preemption. The rules of preemption remain unchanged, still based on preemption. The rules of preemption remain unchanged, still based on
holding priority. holding priority.
7.4.7. Flow Identification and Traffic Balance 7.4.7. Flow Identification and Traffic Balance
The following describe either the state of the art in flow The following describe either the state of the art in flow
identification and traffic balance or propose changes: Section 7.2.4, identification and traffic balance or propose changes: Section 7.2.4,
Section 7.2.5, Section 7.2.7, and Section 7.2.8. Section 7.2.5, Section 7.2.7, and Section 7.2.8.
8. Security Considerations 8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
The security considerations for MPLS/GMPLS and for MPLS-TP are The security considerations for MPLS/GMPLS and for MPLS-TP are
documented in [RFC5920] and [I-D.ietf-mpls-tp-security-framework]. documented in [RFC5920] and [I-D.ietf-mpls-tp-security-framework].
The types protocol extensions proposed in this framework document The types protocol extensions proposed in this framework document
provide additional information about links, forwarding adjacencies, provide additional information about links, forwarding adjacencies,
and LSP requirements. The protocol semantics changes described in and LSP requirements. The protocol semantics changes described in
this framework document propose additional LSP constraints applied at this framework document propose additional LSP constraints applied at
path computation time and at LSP admission at midpoints LSR. The path computation time and at LSP admission at midpoints LSR. The
additional information and constraints provide no additional security additional information and constraints provide no additional security
considerations beyond the security considerations already documented considerations beyond the security considerations already documented
in [RFC5920] and [I-D.ietf-mpls-tp-security-framework]. in [RFC5920] and [I-D.ietf-mpls-tp-security-framework].
9. Acknowledgments 10. Acknowledgments
Authors would like to thank Adrian Farrel, Fred Jounay, Yuji Kamite Authors would like to thank Adrian Farrel, Fred Jounay, Yuji Kamite
for his extensive comments and suggestions regarding early versions for his extensive comments and suggestions regarding early versions
of this document, Ron Bonica, Nabil Bitar, Eric Gray, Lou Berger, and of this document, Ron Bonica, Nabil Bitar, Eric Gray, Lou Berger, and
Kireeti Kompella for their reviews of early versions and great Kireeti Kompella for their reviews of early versions and great
suggestions. suggestions.
Authors would like to thank Iftekhar Hussain for review and Authors would like to thank Iftekhar Hussain for review and
suggestions regarding recent versions of this document. suggestions regarding recent versions of this document.
In the interest of full disclosure of affiliation and in the interest In the interest of full disclosure of affiliation and in the interest
of acknowledging sponsorship, past affiliations of authors are noted. of acknowledging sponsorship, past affiliations of authors are noted.
Much of the work done by Ning So occurred while Ning was at Verizon. Much of the work done by Ning So occurred while Ning was at Verizon.
Much of the work done by Curtis Villamizar occurred while at Much of the work done by Curtis Villamizar occurred while at
Infinera. Infinera continues to sponsor this work on a consulting Infinera. Infinera continues to sponsor this work on a consulting
basis. basis.
10. References 11. References
10.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.
[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,
skipping to change at page 37, line 30 skipping to change at page 37, line 33
February 2011. February 2011.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, [RFC6391] 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 Packet Switched Network", RFC 6391, over an MPLS Packet Switched Network", RFC 6391,
November 2011. November 2011.
10.2. Informative References 11.2. Informative References
[DBP] Bertsekas, D., "Dynamic Behavior of Shortest Path Routing [DBP] Bertsekas, D., "Dynamic Behavior of Shortest Path Routing
Algorithms for Communication Networks", IEEE Trans. Auto. Algorithms for Communication Networks", IEEE Trans. Auto.
Control 1982. Control 1982.
[I-D.ietf-mpls-entropy-label] [I-D.ietf-mpls-entropy-label]
Drake, J., Kompella, K., Yong, L., Amante, S., and W. Kompella, K., Drake, J., Amante, S., Henderickx, W., and
Henderickx, "The Use of Entropy Labels in MPLS L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
Forwarding", draft-ietf-mpls-entropy-label-01 (work in draft-ietf-mpls-entropy-label-04 (work in progress),
progress), October 2011. July 2012.
[I-D.ietf-mpls-explicit-resource-control-bundle] [I-D.ietf-mpls-explicit-resource-control-bundle]
Zamfir, A., Ali, Z., and P. Dimitri, "Component Link Zamfir, A., Ali, Z., and P. Dimitri, "Component Link
Recording and Resource Control for TE Links", Recording and Resource Control for TE Links",
draft-ietf-mpls-explicit-resource-control-bundle-10 (work draft-ietf-mpls-explicit-resource-control-bundle-10 (work
in progress), April 2011. in progress), April 2011.
[I-D.ietf-mpls-tp-security-framework] [I-D.ietf-mpls-tp-security-framework]
Niven-Jenkins, B., Fang, L., Graveman, R., and S. Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Mansfield, "MPLS-TP Security Framework",
draft-ietf-mpls-tp-security-framework-02 (work in Graveman, "MPLS-TP Security Framework",
progress), October 2011. draft-ietf-mpls-tp-security-framework-04 (work in
progress), July 2012.
[I-D.ietf-rtgwg-cl-requirement] [I-D.ietf-rtgwg-cl-requirement]
Malis, A., Villamizar, C., McDysan, D., Yong, L., and N. Villamizar, C., McDysan, D., Ning, S., Malis, A., and L.
So, "Requirements for MPLS Over a Composite Link", Yong, "Requirements for MPLS Over a Composite Link",
draft-ietf-rtgwg-cl-requirement-05 (work in progress), draft-ietf-rtgwg-cl-requirement-07 (work in progress),
January 2012. June 2012.
[I-D.ietf-rtgwg-cl-use-cases]
Ning, S., Malis, A., McDysan, D., Yong, L., and C.
Villamizar, "Composite Link Use Cases and Design
Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in
progress), August 2012.
[I-D.kompella-mpls-rsvp-ecmp] [I-D.kompella-mpls-rsvp-ecmp]
Kompella, K., "Multi-path Label Switched Paths Signaled Kompella, K., "Multi-path Label Switched Paths Signaled
Using RSVP-TE", draft-kompella-mpls-rsvp-ecmp-01 (work in Using RSVP-TE", draft-kompella-mpls-rsvp-ecmp-01 (work in
progress), October 2011. progress), October 2011.
[I-D.ospf-cc-stlv] [I-D.ospf-cc-stlv]
Osborne, E., "Component and Composite Link Membership in Osborne, E., "Component and Composite Link Membership in
OSPF", draft-ospf-cc-stlv-00 (work in progress), OSPF", draft-ospf-cc-stlv-00 (work in progress),
August 2011. August 2011.
[I-D.symmvo-rtgwg-cl-use-cases]
Malis, A., Villamizar, C., McDysan, D., Yong, L., and N.
So, "Composite Link USe Cases and Design Considerations",
draft-symmvo-rtgwg-cl-use-cases-00 (work in progress),
February 2012.
[I-D.villamizar-mpls-tp-multipath] [I-D.villamizar-mpls-tp-multipath]
Villamizar, C., "Use of Multipath with MPLS-TP and MPLS", Villamizar, C., "Use of Multipath with MPLS-TP and MPLS",
draft-villamizar-mpls-tp-multipath-01 (work in progress), draft-villamizar-mpls-tp-multipath-02 (work in progress),
March 2011. February 2012.
[I-D.villamizar-mpls-tp-multipath-te-extn] [I-D.villamizar-mpls-tp-multipath-te-extn]
Villamizar, C., "Multipath Extensions for MPLS Traffic Villamizar, C., "Multipath Extensions for MPLS Traffic
Engineering", Engineering",
draft-villamizar-mpls-tp-multipath-te-extn-00 (work in draft-villamizar-mpls-tp-multipath-te-extn-01 (work in
progress), July 2011. progress), February 2012.
[I-D.wang-ccamp-latency-te-metric] [I-D.wang-ccamp-latency-te-metric]
Fu, X., Betts, M., Wang, Q., McDysan, D., and A. Malis, Fu, X., Betts, M., Wang, Q., McDysan, D., and A. Malis,
"GMPLS extensions to communicate latency as a traffic "GMPLS extensions to communicate latency as a traffic
engineering performance metric", engineering performance metric",
draft-wang-ccamp-latency-te-metric-03 (work in progress), draft-wang-ccamp-latency-te-metric-03 (work in progress),
March 2011. March 2011.
[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
 End of changes. 18 change blocks. 
39 lines changed or deleted 45 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/