A Framework for
Point-to-Multipoint MPLS in Transport Networks
Blue Sun
frost@mm.st
Cisco Systems
stbryant@cisco.com
Alcatel-Lucent
Voyager Place, Shoppenhangers Road
Maidenhead
Berks
SL6 2PJ
United Kingdom
matthew.bocci@alcatel-lucent.com
LabN Consulting
+1-301-468-9228
lberger@labn.net
Routing
MPLS Working Group
mpls-tp
MPLS
Internet-Draft
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 that are applicable specifically to supporting point-to-multipoint
transport paths.
The Multiprotocol Label Switching Transport Profile (MPLS-TP)
is the common set of MPLS protocol functions defined to meet the
requirements specified in . The MPLS-TP
Framework provides an overall
introduction to the MPLS-TP and defines the general architecture of the
Transport Profile, as well as the 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 defines the elements and functions of the MPLS-TP
architecture related to supporting point-to-multipoint transport
paths. The reader is referred to for
the aspects of the MPLS-TP architecture that are generic or are
concerned specifically with point-to-point transport paths.
Term
Definition
CE
Customer Edge
LSP
Label Switched Path
LSR
Label Switching Router
MEG
Maintenance Entity Group
MEP
Maintenance Entity Group End Point
MIP
Maintenance Entity Group Intermediate Point
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
tLDP
Targeted LDP
Detailed definitions and additional terminology may be found in
and .
The point-to-multipoint connectivity provided by an MPLS-TP
network is based on the point-to-multipoint connectivity
provided by MPLS networks. Traffic Engineered P2MP LSP support
is discussed in and , and P2MP PW support is being
developed based on and . MPLS-TP
point-to-multipoint connectivity is analogous to that provided
by traditional transport technologies such as Optical
Transport Network point-to-multipoint and drop-and-continue , and thus supports the same class of
traditional applications, e.g., video distribution.
The scope of this document is limited to
point-to-multipoint functions and it does not discuss
multipoint-to-multipoint support.
The requirements for MPLS-TP are specified in , , and
. 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 RFC 2119 conformance language used in the original
documents as this document is not authoritative.
From :
MPLS-TP must support traffic-engineered point-to-multipoint
transport paths.
MPLS-TP must support unidirectional point-to-multipoint
transport paths.
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.
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.
Recovery techniques used for P2P and P2MP should be identical to
simplify implementation and operation.
Unidirectional 1+1 and 1:n protection for P2MP connectivity must
be supported.
MPLS-TP recovery in a ring must protect unidirectional P2MP
transport paths.
From :
The protocol solution(s) developed to perform the
following OAM functions must also apply to point-to-point
associated bidirectional LSPs, point-to-point unidirectional
LSPs, and point-to-multipoint LSPs:
Continuity Check
Connectivity Verification, proactive
Lock Instruct
Lock Reporting
Alarm Reporting
Client Failure Indication
Packet Loss Measurement
Packet Delay Measurement
The protocol solution(s) developed to perform the
following OAM functions may also apply to point-to-point
associated bidirectional LSPs, point-to-point unidirectional
LSPs, and point-to-multipoint LSPs:
Connectivity Verification, on-demand
Route Tracing
Diagnostic Tests
Remote Defect Indication
From :
For unidirectional (P2P and point-to-multipoint (P2MP))
connection, proactive measurement of packet loss and loss
ratio is required.
For a unidirectional (P2P and P2MP) connection, on-demand
measurement of delay measurement is required.
The overall architecture of the MPLS-TP is defined in
. The architecture for point-to-multipoint
MPLS-TP comprises the following additional elements and functions:
Unidirectional point-to-multipoint LSPs
Unidirectional point-to-multipoint PWs
Optional point-to-multipoint LSP and PW control planes
Survivability, network management, and Operations, Administration,
and Maintenance functions for point-to-multipoint PWs and
LSPs.
The following subsection summarises 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.
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 and the related data-plane behaviour was
further clarified in . 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 , but such
definition is for further study.
The requirements for MPLS-TP OAM are specified in . The overall OAM architecture for
MPLS-TP is defined in , 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 towards all the leaves, and thus may be processed by all
the MIPs and MEPs associated with 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, Time-to-Live-based addressing is used to set the radius and
additional information in the OAM payload is used to identify
the specific destination. It is worth noting that a MIP and MEP
may be instantiated on a single node when it is both a branch
and leaf 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 .
A more detailed discussion of P2MP OAM considerations can be
found in .
The framework for the MPLS-TP control plane is provided in . 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 apply equally to P2P and P2MP
transport paths. The key P2MP-specific control-plane requirements are:
requirement 6 (P2MP transport paths),
requirement 34 (use P2P sub-layers),
requirement 49 (common recovery solutions for P2P and P2MP),
requirement 59 (1+1 protection),
requirement 62 (1:n protection), and
requirement 65 (1:n shared mesh recovery).
defines the control-plane
approach used to support MPLS-TP transport paths. It identifies
GMPLS as the control plane for MPLS-TP LSPs and tLDP 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. Paraphrasing from :
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.
The MPLS-TP control plane for P2MP LSPs uses
GMPLS and is based on RSVP-TE for P2MP LSPs as
defined in . A detailed listing
of how GMPLS satisfies MPLS-TP control-plane requirements is
provided in .
notes that recovery
techniques for traffic engineered P2MP LSPs are not formally
defined, and that such a definition is needed. A formal
definition will be based on existing RFCs and may not require
any new protocol mechanisms but, nonetheless, should be
documented. GMPLS recovery is defined in and . Protection of P2MP LSPs is also
discussed in Section 4.7.3.
The MPLS-TP control plane for P2MP PWs
should be based on the LDP control protocol used for
point-to-point PWs , with
updates as required for P2MP applications. A detailed
specification of the control plane for P2MP PWs is for
further study.
The overall survivability architecture for MPLS-TP is defined
in , and Section 4.7.3 of that RFC 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 impacting delivery
to any of the leaves. Fault notification happens from the node
identifying the fault to the root node via an out-of-band path.
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;
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.
An overview of network management considerations for MPLS-TP
can be found in Section 3.14 of . The provided
description applies equally to P2MP transport paths.
The network management architecture and requirements for
MPLS-TP are specified in . They
derive from the generic specifications described in ITU-T
G.7710/Y.1701 for transport
technologies. They also incorporate the OAM requirements for
MPLS networks and MPLS-TP
networks and expand on those
requirements to cover the modifications necessary for fault,
configuration, performance, and security in a transport network.
covers all MPLS-TP connection
types, including P2MP.
provides the MIB-based
architecture for MPLS-TP. It reviews the interrelationships
between different MIB modules that are not MPLS-TP specific
and 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, .
General security considerations for MPLS-TP are covered in . Additional security considerations for
P2MP LSPs are provided in .
This document introduces no new security considerations beyond those
covered in those documents.
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Framework and Requirements for Virtual Private Multicast Service (VPMS)
This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS.
Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The MIB module defined in this document is applicable to P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC 3812. It is equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802.
Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS PSNs
This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW) over MPLS PSNs. The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, Point-to- Multipoint PWs can be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service) as defined in the Layer 2 Virtual Private Network Working Group.
Point-to-Multipoint Pseudo-Wire Encapsulation
A Point-to-Multipoint (P2MP) Pseudowire (PW) is a mechanism that emulates the essential attributes of a P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). This document describes the encapsulation and data plane procedures for a P2MP PW. These procedures are meant to be independent of the control plane used to signal a P2MP PW.
Framework for Point-to-Multipoint MPLS-TP OAM
The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport. This document discusses and specifies the P2MP framework primarily related to OAM and related management in MPLS-TP networks. This document mainly refers to RFC5654 and RFC6371. The main focus is on the details that are not covered or not clarified in relevant RFCs such as RFC5654, RFC5860, RFC5921, RFC5951, RFC6371, and draft-mpls- tp-p2mp-framework. Note: This I-D was made and updated including the discussions in ITU-T SG15, which were described in Liaison Statements such as (https://datatracker.ietf.org/liaison/1235/) This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications 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.
Common equipment management function requirements
ITU-T
Terms and definitions for synchronous digital hierarchy (SDH)
networks
ITU-T
Characteristics of optical transport network hierarchy
equipment functional blocks
ITU-T