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/