draft-ietf-mpls-multipath-use-00.txt   draft-ietf-mpls-multipath-use-01.txt 
MPLS C. Villamizar, Ed. MPLS C. Villamizar, Ed.
Internet-Draft Outer Cape Cod Network Internet-Draft Outer Cape Cod Network
Intended status: Informational Consulting Intended status: Informational Consulting
Expires: August 23, 2013 February 19, 2013 Expires: March 15, 2014 September 11, 2013
Use of Multipath with MPLS-TP and MPLS Use of Multipath with MPLS-TP and MPLS
draft-ietf-mpls-multipath-use-00 draft-ietf-mpls-multipath-use-01
Abstract Abstract
Many MPLS implementations have supported multipath techniques and Many MPLS implementations have supported multipath techniques and
many MPLS deployments have used multipath techniques, particularly in many MPLS deployments have used multipath techniques, particularly in
very high bandwidth applications, such as provider IP/MPLS core very high bandwidth applications, such as provider IP/MPLS core
networks. MPLS-TP has strongly discouraged the use of multipath networks. MPLS-TP has strongly discouraged the use of multipath
techniques. Some degradation of MPLS-TP OAM performance cannot be techniques. Some degradation of MPLS-TP OAM performance cannot be
avoided when operating over many types of multipath implementations. avoided when operating over many types of multipath implementations.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 August 23, 2013. This Internet-Draft will expire on March 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . . 5 3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . . 5
3.1. MPLS-TP Forwarding and Server Layer Requirements . . . . . 6 3.1. MPLS-TP Forwarding and Server Layer Requirements . . . . . 6
3.2. Methods of Supporting MPLS-TP client LSPs over MPLS . . . 7 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS . . . 7
4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . . 10 4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Today the requirement to handle large aggregations of traffic, can be Today the requirement to handle large aggregations of traffic, can be
handled by a number of techniques which we will collectively call handled by a number of techniques which we will collectively call
skipping to change at page 10, line 5 skipping to change at page 10, line 5
LSP must be the top level LSP, except as noted above. LSP must be the top level LSP, except as noted above.
If MPLS-TP LSP can be moved among component links, then the Link If MPLS-TP LSP can be moved among component links, then the Link
Bundle all-ones component link can be used or server layer MPLS LSPs Bundle all-ones component link can be used or server layer MPLS LSPs
can be used with no restrictions on the server layer MPLS use of can be used with no restrictions on the server layer MPLS use of
multipath except that Entropy Label must be supported along the multipath except that Entropy Label must be supported along the
entire path. An Entropy Label must be used to insure that all of the entire path. An Entropy Label must be used to insure that all of the
MPLS-TP payload and OAM traffic are carried on the same component, MPLS-TP payload and OAM traffic are carried on the same component,
except during very infrequent transitions due to load balancing. except during very infrequent transitions due to load balancing.
Since the Entropy Label Indicator and Entropy Label are always placed
above the GAL in the stack, the presense of GAL will not affect the
selection of a component link as long as the LSR does not hash on the
label stack entries below the Entropy Label.
An MPLS-TP LSP may not traverse multipath links on the path where An MPLS-TP LSP may not traverse multipath links on the path where
MPLS-TP forwarding requirements cannot be met. Such links include MPLS-TP forwarding requirements cannot be met. Such links include
any using pre-RFC6790 Ethernet Link Aggregation, pre-RFC6790 Link any using pre-RFC6790 Ethernet Link Aggregation, pre-RFC6790 Link
Bundling using the all-ones component link, or other form of Bundling using the all-ones component link, or other form of
multipath not supporting termination of the entropy search at the EL multipath not supporting termination of the entropy search at the EL
label as called for in [RFC6790]. An MPLS-TP LSP must not traverse a label as called for in [RFC6790]. An MPLS-TP LSP must not traverse a
server layer MPLS LSP which traverses any form of multipath not server layer MPLS LSP which traverses any form of multipath not
supporting termination of the entropy search at the EL label. For supporting termination of the entropy search at the EL label. For
this to occur, the MPLS-TP ingress LSR must be aware of these links. this to occur, the MPLS-TP ingress LSR must be aware of these links.
This is the reason for requirement MP#4. This is the reason for requirement MP#4.
skipping to change at page 12, line 13 skipping to change at page 12, line 17
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
This document specifies requirements with discussion of framework for This document specifies requirements with discussion of framework for
solutions using existing MPLS and MPLS-TP mechanisms. The solutions using existing MPLS and MPLS-TP mechanisms. The
requirements and framework are related to the coexistence of MPLS/ requirements and framework are related to the coexistence of MPLS/
GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and
multipath. The combination of MPLS, MPLS-TP, and multipath does not multipath. The combination of MPLS, MPLS-TP, and multipath does not
introduce any new security threats. The security considerations for introduce any new security threats. The security considerations for
MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941].
[I-D.ietf-mpls-tp-security-framework].
9. References 9. References
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.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile", and S. Ueno, "Requirements of an MPLS Transport Profile",
skipping to change at page 12, line 43 skipping to change at page 12, line 46
[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.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
9.2. Informative References 9.2. Informative References
[I-D.ietf-mpls-tp-security-framework]
Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS-TP Security Framework",
draft-ietf-mpls-tp-security-framework-05 (work in
progress), October 2012.
[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/
recommendation.asp?parent=T-REC-G.800>. recommendation.asp?parent=T-REC-G.800>.
skipping to change at page 13, line 40 skipping to change at page 13, line 38
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. Class" Field", RFC 5462, February 2009.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, January 2010. RFC 5714, January 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 2013.
Author's Address Author's Address
Curtis Villamizar (editor) Curtis Villamizar (editor)
Outer Cape Cod Network Consulting Outer Cape Cod Network Consulting
Email: curtis@occnc.com Email: curtis@occnc.com
 End of changes. 8 change blocks. 
12 lines changed or deleted 14 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/