draft-ietf-mpls-tp-p2mp-framework-02.txt   draft-ietf-mpls-tp-p2mp-framework-03.txt 
MPLS Working Group D. Frost, Ed. MPLS Working Group D. Frost, Ed.
Internet-Draft S. Bryant, Ed. Internet-Draft S. Bryant, Ed.
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: April 03, 2014 M. Bocci, Ed. Expires: April 11, 2014 M. Bocci, Ed.
Alcatel-Lucent Alcatel-Lucent
L. Berger, Ed. L. Berger, Ed.
LabN Consulting LabN Consulting
September 30, 2013 October 11, 2013
A Framework for Point-to-Multipoint MPLS in Transport Networks A Framework for Point-to-Multipoint MPLS in Transport Networks
draft-ietf-mpls-tp-p2mp-framework-02 draft-ietf-mpls-tp-p2mp-framework-03
Abstract Abstract
The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP)
is the common set of MPLS protocol functions defined to enable the is the common set of MPLS protocol functions defined to enable the
construction and operation of packet transport networks. The MPLS-TP construction and operation of packet transport networks. The MPLS-TP
supports both point-to-point and point-to-multipoint transport paths. supports both point-to-point and point-to-multipoint transport paths.
This document defines the elements and functions of the MPLS-TP This document defines the elements and functions of the MPLS-TP
architecture applicable specifically to supporting point-to- architecture applicable specifically to supporting point-to-
multipoint transport paths. multipoint transport paths.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 April 03, 2014. This Internet-Draft will expire on April 11, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Additional Definitions and Terminology . . . . . . . 3 1.2.1. Additional Definitions and Terminology . . . . . . . 3
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. MPLS Transport Profile Point-to-Multipoint Requirements . . . 4 2. MPLS Transport Profile Point-to-Multipoint Requirements . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 5 3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 5
4. Operations, Administration and Maintenance (OAM) . . . . . . 5 4. Operations, Administration and Maintenance (OAM) . . . . . . 5
5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 6 5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 7
5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . 7 5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . 7
6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Network Management . . . . . . . . . . . . . . . . . . . . . 7 7. Network Management . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP)
is the common set of MPLS protocol functions defined to meet the is the common set of MPLS protocol functions defined to meet the
skipping to change at page 5, line 33 skipping to change at page 5, line 33
3.1. MPLS-TP Encapsulation and Forwarding 3.1. MPLS-TP Encapsulation and Forwarding
Packet encapsulation and forwarding for MPLS-TP point-to-multipoint Packet encapsulation and forwarding for MPLS-TP point-to-multipoint
LSPs is identical to that for MPLS-TE point-to-multipoint LSPs. LSPs is identical to that for MPLS-TE point-to-multipoint LSPs.
MPLS-TE point-to-multipoint LSPs were introduced in [RFC4875] and the MPLS-TE point-to-multipoint LSPs were introduced in [RFC4875] and the
related data-plane behaviour was further clarified in [RFC5332]. related data-plane behaviour was further clarified in [RFC5332].
MPLS-TP allows for both upstream-assigned and downstream-assigned MPLS-TP allows for both upstream-assigned and downstream-assigned
labels for use with point-to-multipoint LSPs. labels for use with point-to-multipoint LSPs.
Packet encapsulation and forwarding for point-to-multipoint PWs is Packet encapsulation and forwarding for point-to-multipoint PWs has
currently being defined by the PWE3 Working Group been discussed by the PWE3 Working Group
[I-D.raggarwa-pwe3-p2mp-pw-encaps]. [I-D.raggarwa-pwe3-p2mp-pw-encaps], but such definition is for
further study.
4. Operations, Administration and Maintenance (OAM) 4. Operations, Administration and Maintenance (OAM)
The overall OAM architecture for MPLS-TP is defined in [RFC6371], and The overall OAM architecture for MPLS-TP is defined in [RFC6371], and
P2MP OAM design considerations are described in Section 3.7 of that P2MP OAM design considerations are described in Section 3.7 of that
RFC. RFC.
All the traffic sent over a P2MP transport path, including OAM All the traffic sent over a P2MP transport path, including OAM
packets generated by a MEP, is sent (multicast) from the root to all packets generated by a MEP, is sent (multicast) from the root to all
the leaves, thus every OAM packet is sent to all leaves, and thus can the leaves, thus every OAM packet is sent to all leaves, and thus can
skipping to change at page 6, line 11 skipping to change at page 6, line 21
To address a packet to an intermediate node in the tree, TTL based To address a packet to an intermediate node in the tree, TTL based
addressing is used to set the radius and addressing information in addressing is used to set the radius and addressing information in
the OAM payload is used to identify the specific destination node. the OAM payload is used to identify the specific destination node.
P2MP paths are unidirectional; therefore, any return path to an P2MP paths are unidirectional; therefore, any return path to an
originating MEP for on-demand transactions will be out-of-band. Out originating MEP for on-demand transactions will be out-of-band. Out
of band return paths are discussed in Section 3.8 of [RFC5921]. of band return paths are discussed in Section 3.8 of [RFC5921].
Packet Loss and Delay Measurement for MPLS Networks [RFC6374] already Packet Loss and Delay Measurement for MPLS Networks [RFC6374] already
considers the P2MP case and it is not thought that any change is considers the P2MP case and it is not thought that any change is
needed to the MPLS-TP profile of [RFC6374] [RFC6375]. needed to the MPLS-TP profile of [RFC6375].
[Editor's note: Additional information / text has been published in A more detailed discussion of P2MP OAM considerations can be found in
[I-D.hmk-mpls-tp-p2mp-oam-framework]. The Editors will coordinate [I-D.hmk-mpls-tp-p2mp-oam-framework].
with the draft authors to identify which text should be folded into
this document and which should remain in a standalone document.]
5. Control Plane 5. Control Plane
The framework for the MPLS-TP control plane is provided in [RFC6373]. The framework for the MPLS-TP control plane is provided in [RFC6373].
This document reviews MPLS-TP control plane requirements as well as This document reviews MPLS-TP control plane requirements as well as
provides details on how the MPLS-TP control plane satisfies these provides details on how the MPLS-TP control plane satisfies these
requirements. Most of the requirements identified in [RFC6373] apply requirements. Most of the requirements identified in [RFC6373] apply
equally to P2P and P2MP transport paths. The key P2MP specific equally to P2P and P2MP transport paths. The key P2MP specific
control plane requirements are identified in requirement 6 (P2MP control plane requirements are identified in requirement 6 (P2MP
transport paths), 34 (use P2P sub-layers), 49 (common recovery transport paths), 34 (use P2P sub-layers), 49 (common recovery
skipping to change at page 7, line 15 skipping to change at page 7, line 23
Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS
recovery, [RFC4872] and [RFC4873], do not explicitly cover their recovery, [RFC4872] and [RFC4873], do not explicitly cover their
interactions. MPLS-TP requires a formal definition of recovery interactions. MPLS-TP requires a formal definition of recovery
techniques for P2MP LSPs. Such a formal definition will be based on techniques for P2MP LSPs. Such a formal definition will be based on
existing RFCs and may not require any new protocol mechanisms but, existing RFCs and may not require any new protocol mechanisms but,
nonetheless, should be documented. Protection of P2MP LSPs is also nonetheless, should be documented. Protection of P2MP LSPs is also
discussed in [RFC6372] Section 4.7.3. discussed in [RFC6372] Section 4.7.3.
5.2. Point-to-Multipoint PW Control Plane 5.2. Point-to-Multipoint PW Control Plane
The MPLS-TP control plane for point-to-multipoint PWs uses the LDP The MPLS-TP control plane for point-to-multipoint PWs should be based
P2MP signaling extensions for PWs defined in [I-D.ietf-pwe3-p2mp-pw]. on the LDP control protocol used for point-to-point PWs [RFC4447],
This definition is limited to single segment PWs and is based on LDP with updates as required for P2MP applications. A detailed
[RFC5036] with upstream-assigned labels [RFC5331]. The document does specification of the > control plane for P2MP PWs is for further
not address recovery of P2MP PWs. Such recovery can be provided via study.
P2MP LSP recovery as generally discussed in [RFC6372].
Alternatively, PW recovery [RFC6718] can be extended to explicitly
support recovery of P2MP PWs.
6. Survivability 6. Survivability
The overall survivability architecture for MPLS-TP is defined in The overall survivability architecture for MPLS-TP is defined in
[RFC6372], and section 4.7.3 in particular describes the application [RFC6372], and section 4.7.3 in particular describes the application
of linear protection to unidirectional P2MP entities using 1+1 and of linear protection to unidirectional P2MP entities using 1+1 and
1:1 protection architecture. For 1+1, the approach is for the root 1:1 protection architecture. For 1+1, the approach is for the root
of the P2MP tree to bridge the user traffic to both the working and of the P2MP tree to bridge the user traffic to both the working and
protection entities. Each sink/leaf MPLS-TP node selects the traffic protection entities. Each sink/leaf MPLS-TP node selects the traffic
from one entity according to some predetermined criteria. For 1:1, from one entity according to some predetermined criteria. For 1:1,
skipping to change at page 7, line 49 skipping to change at page 8, line 7
as partial tree protection and 1:n protection are for further study. as partial tree protection and 1:n protection are for further study.
The IETF has no experience with P2MP PW survivability as yet, and The IETF has no experience with P2MP PW survivability as yet, and
therefore it is proposed that the P2MP PW survivability will therefore it is proposed that the P2MP PW survivability will
initially rely on the LSP survivability. Further work is needed on initially rely on the LSP survivability. Further work is needed on
this subject, particularly if a requirement emerges to provide this subject, particularly if a requirement emerges to provide
survivability for P2MP PWs in an MPLS-TP context. survivability for P2MP PWs in an MPLS-TP context.
7. Network Management 7. Network Management
An overview of network management considerations for MPLS-TP can be
found in Section 3.14 of "Framework for MPLS in Transport Networks"
[RFC5921]. The provided description applies equally to P2MP
transport paths.
The network management architecture and requirements for MPLS-TP are The network management architecture and requirements for MPLS-TP are
specified in [RFC5951]. They derive from the generic specifications specified in [RFC5951]. They derive from the generic specifications
described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies.
They also incorporate the OAM requirements for MPLS Networks They also incorporate the OAM requirements for MPLS Networks
[RFC4377] and MPLS-TP Networks [RFC5860] and expand on those [RFC4377] and MPLS-TP Networks [RFC5860] and expand on those
requirements to cover the modifications necessary for fault, requirements to cover the modifications necessary for fault,
configuration, performance, and security in a transport network. configuration, performance, and security in a transport network.
[RFC5951] covers all MPLS-TP connection types, including P2MP.
[Editor's note: Decide what if anything needs to be said about P2MP- [RFC6639] provides the MIB-based architecture for MPLS-TP. It
specific network management considerations.] reviews the interrelationships between different non MPLS-TP specific
MIB modules that can be leveraged for MPLS-TP network management, and
Section 3.14 of " Framework for MPLS in Transport Networks" [RFC5921] identifies areas where additional MIB modules are required. While
describe the aspects of network management in the P2P MPLS-TP case. the document does not consider P2MP transport paths, it does provide
This apply to the P2MP case. a foundation for an analysis of areas where MIB module modification
and addition may be needed to fully support P2MP transport paths.
There has also been work in the MPLS working group on a P2MP specific
MIB, [I-D.ietf-mpls-p2mp-te-mib].
8. Security Considerations 8. Security Considerations
General security considerations for MPLS-TP are covered in [RFC5921]. General security considerations for MPLS-TP are covered in [RFC5921].
Additional security considerations for point-to-multipoint LSPs are Additional security considerations for point-to-multipoint LSPs are
provided in [RFC4875]. This document introduces no new security provided in [RFC4875]. This document introduces no new security
considerations beyond those covered in those documents. considerations beyond those covered in those documents.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 9, line 47 skipping to change at page 10, line 14
Koike, Y., Hamano, T., and M. Namiki, "Framework for Koike, Y., Hamano, T., and M. Namiki, "Framework for
Point-to-Multipoint MPLS-TP OAM", draft-hmk-mpls-tp-p2mp- Point-to-Multipoint MPLS-TP OAM", draft-hmk-mpls-tp-p2mp-
oam-framework-02 (work in progress), February 2013. oam-framework-02 (work in progress), February 2013.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] [I-D.ietf-l2vpn-vpms-frmwk-requirements]
Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms- Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms-
frmwk-requirements-05 (work in progress), October 2012. frmwk-requirements-05 (work in progress), October 2012.
[I-D.ietf-mpls-p2mp-te-mib]
Farrel, A., Yasukawa, S., and T. Nadeau, "Point-to-
Multipoint Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB)
module", draft-ietf-mpls-p2mp-te-mib-09 (work in
progress), April 2009.
[I-D.ietf-pwe3-p2mp-pw-requirements] [I-D.ietf-pwe3-p2mp-pw-requirements]
Bocci, M., Heron, G., and Y. Kamite, "Requirements and Bocci, M., Heron, G., and Y. Kamite, "Requirements and
Framework for Point-to-Multipoint Pseudowires over MPLS Framework for Point-to-Multipoint Pseudowires over MPLS
PSNs", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in PSNs", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in
progress), September 2011. progress), September 2011.
[I-D.ietf-pwe3-p2mp-pw] [I-D.ietf-pwe3-p2mp-pw]
Sivabalan, S., Boutros, S., and L. Martini, "Signaling Sivabalan, S., Boutros, S., and L. Martini, "Signaling
Root-Initiated Point-to-Multipoint Pseudowire using LDP", Root-Initiated Point-to-Multipoint Pseudowire using LDP",
draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012. draft-ietf-pwe3-p2mp-pw-04 (work in progress), March 2012.
skipping to change at page 10, line 20 skipping to change at page 10, line 42
[I-D.raggarwa-pwe3-p2mp-pw-encaps] [I-D.raggarwa-pwe3-p2mp-pw-encaps]
Aggarwal, R. and F. JOUNAY, "Point-to-Multipoint Pseudo- Aggarwal, R. and F. JOUNAY, "Point-to-Multipoint Pseudo-
Wire Encapsulation", draft-raggarwa-pwe3-p2mp-pw-encaps-01 Wire Encapsulation", draft-raggarwa-pwe3-p2mp-pw-encaps-01
(work in progress), March 2010. (work in progress), March 2010.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks", RFC for Multi-Protocol Label Switched (MPLS) Networks", RFC
4377, February 2006. 4377, February 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010. Transport Networks", RFC 5860, May 2010.
[RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management
Requirements for MPLS-based Transport Networks", RFC 5951, Requirements for MPLS-based Transport Networks", RFC 5951,
September 2010. September 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks", Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011. RFC 6371, September 2011.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
TP) Survivability Framework", RFC 6372, September 2011. TP) Survivability Framework", RFC 6372, September 2011.
[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
Gray, "MPLS Transport Profile (MPLS-TP) Control Plane Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
Framework", RFC 6373, September 2011. Framework", RFC 6373, September 2011.
[RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label Switching
Transport Profile (MPLS-TP) MIB-Based Management
Overview", RFC 6639, June 2012.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
Redundancy", RFC 6718, August 2012. Redundancy", RFC 6718, August 2012.
Authors' Addresses Authors' Addresses
Dan Frost (editor) Dan Frost (editor)
Cisco Systems Cisco Systems
EMail: danfrost@cisco.com EMail: danfrost@cisco.com
Stewart Bryant (editor) Stewart Bryant (editor)
Cisco Systems Cisco Systems
EMail: stbryant@cisco.com EMail: stbryant@cisco.com
Matthew Bocci (editor) Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Voyager Place, Shoppenhangers Road Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ Maidenhead, Berks SL6 2PJ
United Kingdom United Kingdom
 End of changes. 18 change blocks. 
29 lines changed or deleted 49 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/