Internet DRAFT - draft-fbb-mpls-tp-p2mp-framework
draft-fbb-mpls-tp-p2mp-framework
MPLS Working Group D. Frost, Ed.
Internet-Draft S. Bryant, Ed.
Intended status: Informational Cisco Systems
Expires: July 6, 2013 M. Bocci, Ed.
Alcatel-Lucent
L. Berger, Ed.
LabN Consulting
January 2, 2013
A Framework for Point-to-Multipoint MPLS in Transport Networks
draft-fbb-mpls-tp-p2mp-framework-06
Abstract
The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP)
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.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
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 July 6, 2013.
Copyright Notice
Frost, et al. Expires July 6, 2013 [Page 1]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Additional Definitions and Terminology . . . . . . . . 4
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. MPLS Transport Profile Point-to-Multipoint Requirements . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . . 6
4. Operations, Administration and Maintenance (OAM) . . . . . . . 6
5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 7
5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . . 7
6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Network Management . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Frost, et al. Expires July 6, 2013 [Page 2]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
1. Introduction
The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP)
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.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
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 July 6, 2013 [Page 3]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
1.2. Terminology
Term Definition
------- ------------------------------------------
LSP Label Switched Path
MPLS-TP MPLS Transport Profile
SDH Synchronous Digital Hierarchy
ATM Asynchronous Transfer Mode
OTN Optical Transport Network
OAM Operations, Administration and Maintenance
G-ACh Generic Associated Channel
GAL G-ACh Label
MEP Maintenance End Point
MIP Maintenance Intermediate Point
APS Automatic Protection Switching
SCC Signaling Communication Channel
MCC Management Communication Channel
EMF Equipment Management Function
FM Fault Management
CM Configuration Management
PM Performance Monitoring
LSR Label Switching Router
MPLS-TE MPLS Traffic Engineering
P2MP Point-to-multipoint
PW Pseudowire
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. MPLS TE-LSP support is discussed in [RFC4875] and
[RFC5332], and 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 (OTN) point-
to-multipoint [ref?] and optical drop-and-continue [ref?], and thus
supports the same class of traditional applications.
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-
Frost, et al. Expires July 6, 2013 [Page 4]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
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.
o MPLS-TP must support unidirectional point-to-multipoint (P2MP)
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 Label Switched Paths (LSPs)
o Unidirectional point-to-multipoint pseudowires (PWs)
o Optional point-to-multipoint LSP and PW control planes
o Survivability, network management, and Operations, Administration
and Maintenance (OAM) 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
Frost, et al. Expires July 6, 2013 [Page 5]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
Customer Edge 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 is
currently being defined by the PWE3 Working Group
[I-D.raggarwa-pwe3-p2mp-pw-encaps].
4. Operations, Administration and Maintenance (OAM)
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
simultaneously instrument all the MEs in a P2MP MEG. If an OAM
packet is to be processed by only one 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 it is not thought that any change is
needed to the MPLS-TP profile of [RFC6374] [RFC6375].
[Editor's note: Additional information / text has been published in
[I-D.hmk-mpls-tp-p2mp-oam-framework]. The Editors will coordinate
with the draft authors to identify which text should be folded into
this document and which should remain in a standalone document.]
Frost, et al. Expires July 6, 2013 [Page 6]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
5. Control Plane
The framework for the MPLS-TP control plane is provided in [RFC6373].
This document reviews MPLS-TP control plane requirments 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 identified in requirement 6 (P2MP
transport paths), 34 (use P2P sub-layers), 49 (common recovery
solutions for P2P and P2MP), 59 (1+1 protection), 62 (1:n
protection), and 65 (1:n shared mesh recovery).
[RFC6373] defines the control plane approach used to support MPLS-TP
transport paths. It identifies Generalized MPLS (GMPLS) as the
control plane for MPLS-TP Label Switched Paths (LSPs) and Targeted
LDP (T-LDP) as the control plane for pseudowires (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 Resource Reservation Protocol - Traffic Engineering
(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,
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 uses the LDP
P2MP signaling extensions for PWs defined in [I-D.ietf-pwe3-p2mp-pw].
Frost, et al. Expires July 6, 2013 [Page 7]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
This definition is limited to single segment PWs and is based on LDP
[RFC5036] with upstream-assigned labels [RFC5331]. The document does
not address recovery of P2MP PWs. Such recovery can be provided via
P2MP LSP recovery as generally discussed in [RFC6372].
Alternatively, PW recovery [RFC6718] can be extended to explicitly
support recovery of P2MP PWs.
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. 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. Fault
notification happens from the node idenifying 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, partiularly if a requiremnet emerges to provide
survivability for P2MP PWs in an MPLS-TP context.
7. Network Management
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.
[Editor's note: Decide what if anything needs to be said about P2MP-
specific network management considerations.]
Section 3.14 of " Framework for MPLS in Transport Networks" [RFC5921]
describe the aspects of network management in the P2P MPLS-TP case.
This apply to the P2MP case.
Frost, et al. Expires July 6, 2013 [Page 8]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
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
IANA considerations resulting from specific elements of MPLS-TP
functionality are detailed in the documents specifying that
functionality. This document introduces no additional IANA
considerations in itself.
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.
[RFC5036] Andersson, L., Minei, I.,
and B. Thomas, "LDP
Specification", RFC 5036,
October 2007.
Frost, et al. Expires July 6, 2013 [Page 9]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
[RFC5331] Aggarwal, R., Rekhter, Y.,
and E. Rosen, "MPLS
Upstream Label Assignment
and Context-Specific Label
Space", RFC 5331,
August 2008.
[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.
[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/07),
"Common equipment
management function
requirements"", 2005.
Frost, et al. Expires July 6, 2013 [Page 10]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
[I-D.hmk-mpls-tp-p2mp-oam-framework] Koike, Y., Hamano, T., and
M. Namiki, "A framework for
Point-to-Multipoint MPLS-TP
OAM", draft-hmk-mpls-tp-
p2mp-oam-framework-01 (work
in progress),
November 2012.
[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-pwe3-p2mp-pw] Sivabalan, S., Boutros, S.,
and L. Martini, "Signaling
Root-Initiated Point-to-
Multipoint Pseudowire using
LDP",
draft-ietf-pwe3-p2mp-pw-04
(work in progress),
March 2012.
[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.
[RFC4377] Nadeau, T., Morrow, M.,
Swallow, G., Allan, D., and
S. Matsushima, "Operations
and Management (OAM)
Requirements for Multi-
Frost, et al. Expires July 6, 2013 [Page 11]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
Protocol Label Switched
(MPLS) Networks", RFC 4377,
February 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.
[RFC6718] Muley, P., Aissaoui, M.,
and M. Bocci, "Pseudowire
Redundancy", RFC 6718,
August 2012.
Frost, et al. Expires July 6, 2013 [Page 12]
Internet-Draft MPLS Transport Profile P2MP Framework January 2013
Authors' Addresses
Dan Frost (editor)
Cisco Systems
EMail: danfrost@cisco.com
Stewart Bryant (editor)
Cisco Systems
Phone:
Fax:
EMail: stbryant@cisco.com
URI:
Matthew Bocci (editor)
Alcatel-Lucent
Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ
United Kingdom
EMail: matthew.bocci@alcatel-lucent.com
Lou Berger (editor)
LabN Consulting
Phone: +1-301-468-9228
EMail: lberger@labn.net
Frost, et al. Expires July 6, 2013 [Page 13]