MPLS Working Group D. Frost
Internet-Draft S. Bryant
Intended status: Informational Cisco Systems
Expires: April 14, 2014 M. Bocci
Alcatel-Lucent
L. Berger
LabN Consulting
October 14, 2013
A Framework for Point-to-Multipoint MPLS in Transport Networks
draft-ietf-mpls-tp-p2mp-framework-04
Abstract
The Multiprotocol Label Switching Transport Profile is the common set
of MPLS protocol functions defined to enable the construction and
operation of packet transport networks. The MPLS-TP supports both
point-to-point and point-to-multipoint transport paths. This
document defines the elements and functions of the MPLS-TP
architecture applicable specifically to supporting point-to-
multipoint transport paths.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Frost, et al. Expires April 14, 2014 [Page 1]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Additional Definitions and Terminology . . . . . . . 3
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. MPLS Transport Profile Point-to-Multipoint Requirements . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 5
4. Operations, Administration and Maintenance . . . . . . . . . 5
5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 6
5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . 7
6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Network Management . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
1. Introduction
The Multiprotocol Label Switching Transport Profile is the common set
of MPLS protocol functions defined to meet the requirements specified
in [RFC5654]. The MPLS-TP Framework [RFC5921] provides an overall
introduction to the MPLS-TP and defines the general architecture of
the Transport Profile, as well as those aspects specific to point-to-
point transport paths. The purpose of this document is to define the
elements and functions of the MPLS-TP architecture applicable
specifically to supporting point-to-multipoint transport paths.
1.1. Scope
This document defines the elements and functions of the MPLS-TP
architecture related to supporting point-to-multipoint transport
paths. The reader is referred to [RFC5921] for those aspects of the
MPLS-TP architecture that are generic, or concerned specifically with
point-to-point transport paths.
Frost, et al. Expires April 14, 2014 [Page 2]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
1.2. Terminology
Term Definition
------- ---------------------------------------------------
CE Customer Edge
GMPLS Generalized MPLS
LDP Label Distribution Protocol
LSP Label Switched Path
LSR Label Switching Router
MEP Maintenance End Point
MPLS Multiprotocol Label Switching
MPLS-TE MPLS Traffic Engineering
MPLS-TP MPLS Transport Profile
OAM Operations, Administration and Maintenance
OTN Optical Transport Network
P2MP Point-to-multipoint
PW Pseudowire
RSVP-TE Resource Reservation Protocol - Traffic Engineering
SDH Synchronous Digital Hierarchy
T-LDP Targeted LDP
1.2.1. Additional Definitions and Terminology
Detailed definitions and additional terminology may be found in
[RFC5921] and [RFC5654].
1.3. Applicability
The point-to-multipoint connectivity provided by an MPLS-TP network
is based on the point-to-multipoint connectivity provided by MPLS
networks. P2MP MPLS TE-LSP support is discussed in [RFC4875] and
[RFC5332], and P2MP PW support is being developed based on
[I-D.ietf-pwe3-p2mp-pw-requirements] and
[I-D.ietf-l2vpn-vpms-frmwk-requirements]. MPLS-TP point-to-
multipoint connectivity is analogous to that provided by traditional
transport technologies such as Optical Transport Network point-to-
multipoint [G.798] and drop-and-continue [G.780], and thus supports
the same class of traditional applications, e.g., video distribution.
There is no definition for MPLS TE-LSP support of multipoint-to-
multipoint connectivity and none is anticipated.
Frost, et al. Expires April 14, 2014 [Page 3]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
2. MPLS Transport Profile Point-to-Multipoint Requirements
The requirements for MPLS-TP are specified in [RFC5654], [RFC5860],
and [RFC5951]. This section provides a brief summary of point-to-
multipoint transport requirements as set out in those documents; the
reader is referred to the documents themselves for the definitive and
complete list of requirements. This summary does not include the
[RFC2119] conformance language used in original documents as this
document is not authoritative.
o MPLS-TP must support unidirectional point-to-multipoint transport
paths.
o MPLS-TP must support traffic-engineered point-to-multipoint
transport paths.
o MPLS-TP must be capable of using P2MP server (sub)layer
capabilities as well as P2P server (sub)layer capabilities when
supporting P2MP MPLS-TP transport paths.
o The MPLS-TP control plane must support establishing all the
connectivity patterns defined for the MPLS-TP data plane (i.e.,
unidirectional P2P, associated bidirectional P2P, co-routed
bidirectional P2P, unidirectional P2MP) including configuration of
protection functions and any associated maintenance functions.
o Recovery techniques used for P2P and P2MP should be identical to
simplify implementation and operation.
o Unidirectional 1+1 and 1:n protection for P2MP connectivity must
be supported.
o MPLS-TP recovery in a ring must protect unidirectional P2MP
transport paths.
3. Architecture
The overall architecture of the MPLS Transport Profile is defined in
[RFC5921]. The architecture for point-to-multipoint MPLS-TP
comprises the following additional elements and functions:
o Unidirectional point-to-multipoint LSPs
o Unidirectional point-to-multipoint PWs
o Optional point-to-multipoint LSP and PW control planes
Frost, et al. Expires April 14, 2014 [Page 4]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
o Survivability, network management, and Operations, Administration
and Maintenance functions for point-to-multipoint PWs and LSPs
The following subsections summarise the encapsulation and forwarding
of point-to-multipoint traffic within an MPLS-TP network, and the
encapsulation options for delivery of traffic to and from MPLS-TP CE
devices when the network is providing a packet transport service.
3.1. MPLS-TP Encapsulation and Forwarding
Packet encapsulation and forwarding for MPLS-TP point-to-multipoint
LSPs is identical to that for MPLS-TE point-to-multipoint LSPs.
MPLS-TE point-to-multipoint LSPs were introduced in [RFC4875] and the
related data-plane behaviour was further clarified in [RFC5332].
MPLS-TP allows for both upstream-assigned and downstream-assigned
labels for use with point-to-multipoint LSPs.
Packet encapsulation and forwarding for point-to-multipoint PWs has
been discussed within the PWE3 Working Group
[I-D.raggarwa-pwe3-p2mp-pw-encaps], but such definition is for
further study.
4. Operations, Administration and Maintenance
The overall OAM architecture for MPLS-TP is defined in [RFC6371], and
P2MP OAM design considerations are described in Section 3.7 of that
RFC.
All the traffic sent over a P2MP transport path, including OAM
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
impact all the MEs in a P2MP MEG. If an OAM packet is to be
processed by only a specific leaf, it requires information to
indicate to all other leaves that the packet must be discarded. To
address a packet to an intermediate node in the tree, TTL based
addressing is used to set the radius and addressing information in
the OAM payload is used to identify the specific destination node.
P2MP paths are unidirectional; therefore, any return path to an
originating MEP for on-demand transactions will be out-of-band. Out
of band return paths are discussed in Section 3.8 of [RFC5921].
Packet Loss and Delay Measurement for MPLS Networks [RFC6374] already
considers the P2MP case and no change is needed to the MPLS-TP
profile of [RFC6375].
A more detailed discussion of P2MP OAM considerations can be found in
[I-D.hmk-mpls-tp-p2mp-oam-framework].
Frost, et al. Expires April 14, 2014 [Page 5]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
5. Control Plane
The framework for the MPLS-TP control plane is provided in [RFC6373].
This document reviews MPLS-TP control plane requirements as well as
provides details on how the MPLS-TP control plane satisfies these
requirements. Most of the requirements identified in [RFC6373] apply
equally to P2P and P2MP transport paths. The key P2MP specific
control plane requirements are:
o requirement 6 (P2MP transport paths),
o requirement 34 (use P2P sub-layers),
o requirement 49 (common recovery solutions for P2P and P2MP),
o requirement 59 (1+1 protection),
o requirement 62 (1:n protection),
o and requirement 65 (1:n shared mesh recovery).
[RFC6373] defines the control plane approach used to support MPLS-TP
transport paths. It identifies GMPLS as the control plane for MPLS-
TP LSPs T-LDP as the control plane for PWs. MPLS-TP allows that
either, or both, LSPs and PWs to be provisioned statically or via a
control plane. As noted in [RFC6373]:
The PW and LSP control planes, collectively, must satisfy the MPLS-TP
control-plane requirements. As with P2P services, when P2MP client
services are provided directly via LSPs, all requirements must be
satisfied by the LSP control plane. When client services are
provided via PWs, the PW and LSP control planes can operate in
combination, and some functions may be satisfied via the PW control
plane while others are provided to PWs by the LSP control plane.
This is particularly noteworthy for P2MP recovery.
5.1. Point-to-Multipoint LSP Control Plane
The MPLS-TP control plane for point-to-multipoint LSPs uses GMPLS and
is based on RSVP-TE for point-to-multipoint LSPs as defined in
[RFC4875]. A detailed listing of how GMPLS satisfies MPLS-TP control
plane requirements is provided in [RFC6373].
Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS
recovery, [RFC4872] and [RFC4873], do not explicitly cover their
interactions. MPLS-TP requires a formal definition of recovery
techniques for P2MP LSPs. Such a formal definition will be based on
existing RFCs and may not require any new protocol mechanisms but,
Frost, et al. Expires April 14, 2014 [Page 6]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
nonetheless, should be documented. Protection of P2MP LSPs is also
discussed in [RFC6372] Section 4.7.3.
5.2. Point-to-Multipoint PW Control Plane
The MPLS-TP control plane for point-to-multipoint PWs should be based
on the LDP control protocol used for point-to-point PWs [RFC4447],
with updates as required for P2MP applications. A detailed
specification of the control plane for P2MP PWs is for further study.
6. Survivability
The overall survivability architecture for MPLS-TP is defined in
[RFC6372], and section 4.7.3 in particular describes the application
of linear protection to unidirectional P2MP entities using 1+1 and
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
protection entities. Each sink/leaf MPLS-TP node selects the traffic
from one entity according to some predetermined criteria. For 1:1,
the source/root MPLS-TP node needs to identify the existence of a
fault condition on any of the branches of the network. Fault
notification happens from the node identifying the fault to the root
node and from the leaves to the root via an out of band path. In
either case the root then selects the protection transport path for
traffic transfer. More sophisticated survivability approaches such
as partial tree protection and 1:n protection are for further study.
The IETF has no experience with P2MP PW survivability as yet, and
therefore it is proposed that the P2MP PW survivability will
initially rely on the LSP survivability. Further work is needed on
this subject, particularly if a requirement emerges to provide
survivability for P2MP PWs in an MPLS-TP context.
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
specified in [RFC5951]. They derive from the generic specifications
described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies.
They also incorporate the OAM requirements for MPLS Networks
[RFC4377] and MPLS-TP Networks [RFC5860] and expand on those
requirements to cover the modifications necessary for fault,
configuration, performance, and security in a transport network.
[RFC5951] covers all MPLS-TP connection types, including P2MP.
Frost, et al. Expires April 14, 2014 [Page 7]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
[RFC6639] provides the MIB-based architecture for MPLS-TP. It
reviews the interrelationships between different non MPLS-TP specific
MIB modules that can be leveraged for MPLS-TP network management, and
identifies areas where additional MIB modules are required. While
the document does not consider P2MP transport paths, it does provide
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
General security considerations for MPLS-TP are covered in [RFC5921].
Additional security considerations for point-to-multipoint LSPs are
provided in [RFC4875]. This document introduces no new security
considerations beyond those covered in those documents.
9. IANA Considerations
There are no requests for IANA actions in this document.
10. References
10.1. Normative References
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010.
Frost, et al. Expires April 14, 2014 [Page 8]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay
Measurement Profile for MPLS-Based Transport Networks",
RFC 6375, September 2011.
10.2. Informative References
[G.7710] ITU-T Recommendation G.7710/Y.1701 (07/2007), "Common
equipment management function requirements", 2007.
[G.780] ITU-T Recommendation G.780//Y.1351 (07/2010), "Terms and
definitions for synchronous digital hierarchy (SDH)
networks", 2010.
[G.798] ITU-T Recommendation G.798 (10/2010), "Characteristics of
optical transport network hierarchy equipment functional
blocks", 2010.
[I-D.hmk-mpls-tp-p2mp-oam-framework]
Koike, Y., Hamano, T., and M. Namiki, "Framework for
Point-to-Multipoint MPLS-TP OAM", draft-hmk-mpls-tp-p2mp-
oam-framework-02 (work in progress), February 2013.
[I-D.ietf-l2vpn-vpms-frmwk-requirements]
Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms-
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]
Bocci, M., Heron, G., and Y. Kamite, "Requirements and
Framework for Point-to-Multipoint Pseudowires over MPLS
PSNs", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in
progress), September 2011.
[I-D.raggarwa-pwe3-p2mp-pw-encaps]
Aggarwal, R. and F. JOUNAY, "Point-to-Multipoint Pseudo-
Wire Encapsulation", draft-raggarwa-pwe3-p2mp-pw-encaps-01
(work in progress), March 2010.
Frost, et al. Expires April 14, 2014 [Page 9]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks", RFC
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
Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010.
[RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management
Requirements for MPLS-based Transport Networks", RFC 5951,
September 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
TP) Survivability Framework", RFC 6372, September 2011.
[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
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.
Authors' Addresses
Dan Frost
Cisco Systems
EMail: danfrost@cisco.com
Stewart Bryant
Cisco Systems
EMail: stbryant@cisco.com
Frost, et al. Expires April 14, 2014 [Page 10]
Internet-Draft MPLS Transport Profile P2MP Framework October 2013
Matthew Bocci
Alcatel-Lucent
Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ
United Kingdom
EMail: matthew.bocci@alcatel-lucent.com
Lou Berger
LabN Consulting
Phone: +1-301-468-9228
EMail: lberger@labn.net
Frost, et al. Expires April 14, 2014 [Page 11]