One document matched: draft-fbb-mpls-tp-p2mp-framework-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="3"?>
<?rfc rfcedstyle="yes"?>
<rfc category="info" docName="draft-fbb-mpls-tp-p2mp-framework-05"
ipr="trust200902">
<front>
<title abbrev="MPLS Transport Profile P2MP Framework">A Framework for
Point-to-Multipoint MPLS in Transport Networks</title>
<author fullname="Dan Frost" initials="D" role="editor" surname="Frost">
<organization>Cisco Systems</organization>
<address>
<email>danfrost@cisco.com</email>
</address>
</author>
<author fullname="Stewart Bryant" initials="S" role="editor"
surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>stbryant@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Matthew Bocci" initials="M" role="editor"
surname="Bocci">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Voyager Place, Shoppenhangers Road</street>
<city>Maidenhead</city>
<region>Berks</region>
<code>SL6 2PJ</code>
<country>United Kingdom</country>
</postal>
<email>matthew.bocci@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Lou Berger" initials="L" role="editor" surname="Berger">
<organization>LabN Consulting</organization>
<address>
<phone>+1-301-468-9228</phone>
<email>lberger@labn.net</email>
</address>
</author>
<date year="2012" />
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>mpls-tp</keyword>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP)
is the common set of MPLS protocol functions defined to meet the
requirements specified in <xref target="RFC5654"></xref>. The MPLS-TP
Framework <xref target="RFC5921"></xref> 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.</t>
<t>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.</t>
<section title="Scope">
<t>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 <xref target="RFC5921"></xref> for
those aspects of the MPLS-TP architecture that are generic, or
concerned specifically with point-to-point transport paths.</t>
</section>
<section title="Terminology">
<texttable align="left" style="headers">
<ttcol>Term</ttcol>
<ttcol>Definition</ttcol>
<c>LSP</c>
<c>Label Switched Path</c>
<c>MPLS-TP</c>
<c>MPLS Transport Profile</c>
<c>SDH</c>
<c>Synchronous Digital Hierarchy</c>
<c>ATM</c>
<c>Asynchronous Transfer Mode</c>
<c>OTN</c>
<c>Optical Transport Network</c>
<c>OAM</c>
<c>Operations, Administration and Maintenance</c>
<c>G-ACh</c>
<c>Generic Associated Channel</c>
<c>GAL</c>
<c>G-ACh Label</c>
<c>MEP</c>
<c>Maintenance End Point</c>
<c>MIP</c>
<c>Maintenance Intermediate Point</c>
<c>APS</c>
<c>Automatic Protection Switching</c>
<c>SCC</c>
<c>Signaling Communication Channel</c>
<c>MCC</c>
<c>Management Communication Channel</c>
<c>EMF</c>
<c>Equipment Management Function</c>
<c>FM</c>
<c>Fault Management</c>
<c>CM</c>
<c>Configuration Management</c>
<c>PM</c>
<c>Performance Management</c>
<c>LSR</c>
<c>Label Switching Router</c>
<c>MPLS-TE</c>
<c>MPLS Traffic Engineering</c>
<c>P2MP</c>
<c>Point-to-multipoint</c>
<c>PW</c>
<c>Pseudowire</c>
</texttable>
<section title="Additional Definitions and Terminology">
<t>Detailed definitions and additional terminology may be found in
<xref target="RFC5921"></xref> and <xref
target="RFC5654"></xref>.</t>
</section>
</section>
<section title="Applicability">
<t>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 <xref
target="RFC4875"></xref> and <xref target="RFC5332"></xref>, and PW
support is being developed based on <xref
target="I-D.ietf-pwe3-p2mp-pw-requirements"></xref> and <xref
target="I-D.ietf-l2vpn-vpms-frmwk-requirements"></xref>. 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.</t>
</section>
</section>
<section title="MPLS Transport Profile Point-to-Multipoint Requirements">
<t>The requirements for MPLS-TP are specified in <xref
target="RFC5654"></xref>, <xref target="RFC5860"></xref>, and <xref
target="RFC5951"></xref>. 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.</t>
<t><list style="symbols">
<t>MPLS-TP must support unidirectional point-to-multipoint (P2MP)
transport paths.</t>
<t>MPLS-TP must support traffic-engineered point-to-multipoint
transport paths.</t>
<t>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.</t>
<t>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.</t>
<t>Recovery techniques used for P2P and P2MP should be identical to
simplify implementation and operation.</t>
<t>Unidirectional 1+1 and 1:n protection for P2MP connectivity must
be supported.</t>
<t>MPLS-TP recovery in a ring must protect unidirectional P2MP
transport paths.</t>
</list></t>
</section>
<section anchor="arch" title="Architecture">
<t>The overall architecture of the MPLS Transport Profile is defined in
<xref target="RFC5921"></xref>. The architecture for point-to-multipoint
MPLS-TP comprises the following additional elements and functions: <list
style="symbols">
<t>Unidirectional point-to-multipoint Label Switched Paths
(LSPs)</t>
<t>Unidirectional point-to-multipoint pseudowires (PWs)</t>
<t>Optional point-to-multipoint LSP and PW control planes</t>
<t>Survivability, network management, and Operations, Administration
and Maintenance (OAM) functions for point-to-multipoint PWs and
LSPs</t>
</list></t>
<t>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
Customer Edge devices when the network is providing a packet transport
service.</t>
<section title="MPLS-TP Encapsulation and Forwarding">
<t>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 <xref
target="RFC4875"></xref> and the related data-plane behaviour was
further clarified in <xref target="RFC5332"></xref>. MPLS-TP allows
for both upstream-assigned and downstream-assigned labels for use with
point-to-multipoint LSPs.</t>
<t>Packet encapsulation and forwarding for point-to-multipoint PWs is
currently being defined by the PWE3 Working Group <xref
target="I-D.raggarwa-pwe3-p2mp-pw-encaps"></xref>.</t>
</section>
</section>
<section anchor="oam"
title="Operations, Administration and Maintenance (OAM)">
<t>The overall OAM architecture for MPLS-TP is defined in <xref
target="RFC6371"></xref>, and P2MP OAM design considerations are
described in Section 3.7 of that RFC.</t>
<t>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 spacific destination node.</t>
<t>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 <xref
target="RFC5921"></xref></t>
<t>[Editor's note: Additional information / text has been published in
<xref target="I-D.hmk-mpls-tp-p2mp-oam-framework"></xref>. 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.]</t>
</section>
<section anchor="cp" title="Control Plane">
<t>The framework for the MPLS-TP control plane is provided in <xref
target="RFC6373"></xref>. 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
<xref target="RFC6373"> </xref> 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).</t>
<t><xref target="RFC6373"></xref> 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 <xref target="RFC6373"></xref>:</t>
<t>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.</t>
<section title="Point-to-Multipoint LSP Control Plane">
<t>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 <xref
target="RFC4875"></xref>. A detailed listing of how GMPLS satisfies
MPLS-TP control plane requirements is provided in <xref
target="RFC6373"></xref>.</t>
<t>Per <xref target="RFC6373"></xref>, the definitions of P2MP, <xref
target="RFC4875"></xref>, and GMPLS recovery, <xref
target="RFC4872"></xref> and <xref target="RFC4873"></xref>, 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 <xref target="RFC6372"></xref>
Section 4.7.3.</t>
</section>
<section title="Point-to-Multipoint PW Control Plane">
<t><xref target="I-D.ietf-pwe3-p2mp-pw"></xref> The MPLS-TP control
plane for point-to-multipoint PWs uses the LDP P2MP signaling
extensions for PWs defined in <xref
target="I-D.ietf-pwe3-p2mp-pw"></xref>. This definition is limited to
single segment PWs and is based on LDP <xref target="RFC5036"></xref>
with upstream-assigned labels <xref target="RFC5331"></xref>. The
document does not address recovery of P2MP PWs. Such recovery can be
provided via P2MP LSP recovery as generally discussed in <xref
target="RFC6372"></xref>. Alternatively, PW recovery <xref
target="I-D.ietf-pwe3-redundancy"></xref> can be extended to
explicitly support recovery of P2MP PWs.</t>
</section>
</section>
<section anchor="survive" title="Survivability">
<t>The overall survivability architecture for MPLS-TP is defined in
<xref target="RFC6372"></xref>, and section 4.7.3 in particular
describes the application of linear protection to unidirectional P2MP
entities using 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 eather 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.</t>
<t>The IETF has no experience with P2MP PW survivability as yet, and
therefore it is proposed that he P2MP PW survivability will initially
rely on the LSP survivability. Further work is needed on this subject,
partiularly to if a requiremnet emerges to provide survivability for
P2MP PWs in an MPLS-TP context.</t>
</section>
<section anchor="nm" title="Network Management">
<t>The network management architecture and requirements for MPLS-TP are
specified in <xref target="RFC5951"></xref>. They derive from the
generic specifications described in ITU-T G.7710/Y.1701 <xref
target="G.7710"></xref> for transport technologies. They also
incorporate the OAM requirements for MPLS Networks <xref
target="RFC4377"></xref> and MPLS-TP Networks <xref
target="RFC5860"></xref> and expand on those requirements to cover the
modifications necessary for fault, configuration, performance, and
security in a transport network.</t>
<t>[Editor's note: Decide what if anything needs to be said about
P2MP-specific network management considerations.]</t>
<t>Section 3.14 of " Framework for MPLS in Transport Networks" <xref
target="RFC5921"></xref> describe the aspects of network management in
the P2P MPLS-TP case. This apply to the P2MP case. Packet Loss and Delay
Measurement for MPLS Networks <xref target="RFC6374"></xref> already
considers the P2MP case and it is not thought that any change is needed
to the MPLS-TP profile of <xref target="RFC6374"></xref> <xref
target="RFC6375"></xref>.</t>
</section>
<section title="Security Considerations">
<t>General security considerations for MPLS-TP are covered in <xref
target="RFC5921"></xref>. Additional security considerations for
point-to-multipoint LSPs are provided in <xref target="RFC4875"></xref>.
This document introduces no new security considerations beyond those
covered in those documents.</t>
</section>
<section title="IANA Considerations">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.5654'?>
<?rfc include='reference.RFC.5921'?>
<?rfc include='reference.RFC.4875'?>
<?rfc include='reference.RFC.4873'?>
<?rfc include='reference.RFC.4872'?>
<?rfc include='reference.RFC.5332'?>
<?rfc include='reference.RFC.5036'?>
<?rfc include='reference.RFC.5331'?>
<?rfc include='reference.RFC.6374'?>
<?rfc include='reference.RFC.6375'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.5860'?>
<?rfc include='reference.RFC.6371'?>
<?rfc include='reference.RFC.6373'?>
<?rfc include='reference.RFC.5951'?>
<?rfc include='reference.RFC.6372'?>
<?rfc include='reference.I-D.ietf-pwe3-p2mp-pw'?>
<?rfc include='reference.I-D.ietf-l2vpn-vpms-frmwk-requirements'?>
<?rfc include='reference.I-D.ietf-pwe3-p2mp-pw-requirements'?>
<?rfc include='reference.I-D.raggarwa-pwe3-p2mp-pw-encaps'?>
<?rfc include='reference.I-D.ietf-pwe3-redundancy'?>
<?rfc include='reference.RFC.4377'?>
<?rfc include='reference.I-D.hmk-mpls-tp-p2mp-oam-framework'?>
<reference anchor="G.7710">
<front>
<title>ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment
management function requirements"</title>
<author>
<organization></organization>
</author>
<date year="2005" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:27:00 |