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