draft-ietf-mpls-tp-p2mp-framework-06.txt   rfc7167.txt 
MPLS Working Group D. Frost Internet Engineering Task Force (IETF) D. Frost
Internet-Draft Blue Sun Request for Comments: 7167 Blue Sun
Intended status: Informational S. Bryant Category: Informational S. Bryant
Expires: July 21, 2014 Cisco Systems ISSN: 2070-1721 Cisco Systems
M. Bocci M. Bocci
Alcatel-Lucent Alcatel-Lucent
L. Berger L. Berger
LabN Consulting LabN Consulting
January 17, 2014 April 2014
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-06
Abstract Abstract
The Multiprotocol Label Switching Transport Profile is the common set The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the
of MPLS protocol functions defined to enable the construction and common set of MPLS protocol functions defined to enable the
operation of packet transport networks. The MPLS-TP supports both construction and operation of packet transport networks. The MPLS-TP
point-to-point and point-to-multipoint transport paths. This supports both point-to-point and point-to-multipoint transport paths.
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 that are applicable specifically to supporting point-to-
multipoint transport paths. multipoint transport paths.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on July 21, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7167.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Additional Definitions and Terminology . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 3. MPLS-TP P2MP Requirements . . . . . . . . . . . . . . . . . . 4
2. MPLS-TP P2MP Requirements . . . . . . . . . . . . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 6
3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 6 5. Operations, Administration, and Maintenance . . . . . . . . . 6
4. Operations, Administration and Maintenance . . . . . . . . . 6 6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. P2MP LSP Control Plane . . . . . . . . . . . . . . . . . 8
5.1. P2MP LSP Control Plane . . . . . . . . . . . . . . . . . 7 6.2. P2MP PW Control Plane . . . . . . . . . . . . . . . . . . 8
5.2. P2MP PW Control Plane . . . . . . . . . . . . . . . . . . 8 7. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Network Management . . . . . . . . . . . . . . . . . . . . . 9
7. Network Management . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the
common set of MPLS protocol functions defined to meet the common set of MPLS protocol functions defined to meet the
requirements specified in [RFC5654]. The MPLS-TP Framework [RFC5921] requirements specified in [RFC5654]. The MPLS-TP Framework [RFC5921]
provides an overall introduction to the MPLS-TP and defines the provides an overall introduction to the MPLS-TP and defines the
general architecture of the Transport Profile, as well as those general architecture of the Transport Profile, as well as the aspects
aspects specific to point-to-point transport paths. The purpose of specific to point-to-point transport paths. The purpose of this
this document is to define the elements and functions of the MPLS-TP document is to define 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.
1.1. Scope 1.1. Scope
This document defines the elements and functions of the MPLS-TP This document defines the elements and functions of the MPLS-TP
architecture related to supporting point-to-multipoint transport architecture related to supporting point-to-multipoint transport
paths. The reader is referred to [RFC5921] for those aspects of the paths. The reader is referred to [RFC5921] for the aspects of the
MPLS-TP architecture that are generic, or concerned specifically with MPLS-TP architecture that are generic or are concerned specifically
point-to-point transport paths. with point-to-point transport paths.
1.2. Terminology 1.2. Terminology
Term Definition Term Definition
------- --------------------------------------------------- ------- ---------------------------------------------------
CE Customer Edge CE Customer Edge
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
MEG Maintenance Entity Group MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
skipping to change at page 3, line 27 skipping to change at page 3, line 45
MPLS-TE MPLS Traffic Engineering MPLS-TE MPLS Traffic Engineering
MPLS-TP MPLS Transport Profile MPLS-TP MPLS Transport Profile
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
OTN Optical Transport Network OTN Optical Transport Network
P2MP Point-to-multipoint P2MP Point-to-multipoint
PW Pseudowire PW Pseudowire
RSVP-TE Resource Reservation Protocol - Traffic Engineering RSVP-TE Resource Reservation Protocol - Traffic Engineering
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
tLDP Targeted LDP tLDP Targeted LDP
1.2.1. Additional Definitions and Terminology
Detailed definitions and additional terminology may be found in Detailed definitions and additional terminology may be found in
[RFC5921] and [RFC5654]. [RFC5921] and [RFC5654].
1.3. Applicability 2. Applicability
The point-to-multipoint connectivity provided by an MPLS-TP network The point-to-multipoint connectivity provided by an MPLS-TP network
is based on the point-to-multipoint connectivity provided by MPLS is based on the point-to-multipoint connectivity provided by MPLS
networks. Traffic Engineered P2MP LSP support is discussed in networks. Traffic Engineered P2MP LSP support is discussed in
[RFC4875] and [RFC5332], and P2MP PW support is being developed based [RFC4875] and [RFC5332], and P2MP PW support is being developed based
on [I-D.ietf-pwe3-p2mp-pw-requirements] and on [P2MP-PW-REQS] and [VPMS-FRMWK-REQS]. MPLS-TP point-to-multipoint
[I-D.ietf-l2vpn-vpms-frmwk-requirements]. MPLS-TP point-to- connectivity is analogous to that provided by traditional transport
multipoint connectivity is analogous to that provided by traditional technologies such as Optical Transport Network point-to-multipoint
transport technologies such as Optical Transport Network point-to- [G.798] and drop-and-continue [G.780], and thus supports the same
multipoint [G.798] and drop-and-continue [G.780], and thus supports class of traditional applications, e.g., video distribution.
the same class of traditional applications, e.g., video distribution.
The scope of this document is limited to point-to-multipoint The scope of this document is limited to point-to-multipoint
functions and it does not discuss multipoint-to-multipoint support. functions and it does not discuss multipoint-to-multipoint support.
2. MPLS-TP P2MP Requirements 3. MPLS-TP P2MP Requirements
The requirements for MPLS-TP are specified in [RFC5654], [RFC5860], The requirements for MPLS-TP are specified in [RFC5654], [RFC5860],
and [RFC5951]. This section provides a brief summary of point-to- and [RFC5951]. This section provides a brief summary of point-to-
multipoint transport requirements as set out in those documents; the multipoint transport requirements as set out in those documents; the
reader is referred to the documents themselves for the definitive and reader is referred to the documents themselves for the definitive and
complete list of requirements. This summary does not include the complete list of requirements. This summary does not include the RFC
[RFC2119] conformance language used in original documents as this 2119 [BCP14] conformance language used in the original documents as
document is not authoritative. this document is not authoritative.
From [RFC5654]: From [RFC5654]:
o MPLS-TP must support traffic-engineered point-to-multipoint o MPLS-TP must support traffic-engineered point-to-multipoint
transport paths. transport paths.
o MPLS-TP must support unidirectional point-to-multipoint transport o MPLS-TP must support unidirectional point-to-multipoint transport
paths. paths.
o MPLS-TP must be capable of using P2MP server (sub)layer o MPLS-TP must be capable of using P2MP server (sub)layer
skipping to change at page 5, line 38 skipping to change at page 6, line 5
From [RFC5951]: From [RFC5951]:
o For unidirectional (P2P and point-to-multipoint (P2MP)) o For unidirectional (P2P and point-to-multipoint (P2MP))
connection, proactive measurement of packet loss and loss ratio is connection, proactive measurement of packet loss and loss ratio is
required. required.
o For a unidirectional (P2P and P2MP) connection, on-demand o For a unidirectional (P2P and P2MP) connection, on-demand
measurement of delay measurement is required. measurement of delay measurement is required.
3. Architecture 4. Architecture
The overall architecture of the MPLS-TP is defined in [RFC5921]. The The overall architecture of the MPLS-TP is defined in [RFC5921]. The
architecture for point-to-multipoint MPLS-TP comprises the following architecture for point-to-multipoint MPLS-TP comprises the following
additional elements and functions: additional elements and functions:
o Unidirectional point-to-multipoint LSPs o Unidirectional point-to-multipoint LSPs
o Unidirectional point-to-multipoint PWs o Unidirectional point-to-multipoint PWs
o Optional point-to-multipoint LSP and PW control planes o Optional point-to-multipoint LSP and PW control planes
o Survivability, network management, and Operations, Administration o Survivability, network management, and Operations, Administration,
and Maintenance functions for point-to-multipoint PWs and LSPs and Maintenance functions for point-to-multipoint PWs and LSPs.
The following subsections summarise the encapsulation and forwarding The following subsection summarises the encapsulation and forwarding
of point-to-multipoint traffic within an MPLS-TP network, and the of point-to-multipoint traffic within an MPLS-TP network, and the
encapsulation options for delivery of traffic to and from MPLS-TP CE encapsulation options for delivery of traffic to and from MPLS-TP CE
devices when the network is providing a packet transport service. devices when the network is providing a packet transport service.
3.1. MPLS-TP Encapsulation and Forwarding 4.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 has Packet encapsulation and forwarding for point-to-multipoint PWs has
been discussed within the PWE3 Working Group been discussed within the PWE3 Working Group [P2MP-PW-ENCAPS], but
[I-D.raggarwa-pwe3-p2mp-pw-encaps], but such definition is for such definition is for further study.
further study.
4. Operations, Administration and Maintenance 5. Operations, Administration, and Maintenance
The requirements for MPLS-TP OAM are specified in [RFC5860]. The The requirements for MPLS-TP OAM are specified in [RFC5860]. The
overall OAM architecture for MPLS-TP is defined in [RFC6371], and 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 towards 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 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 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 only a specific leaf, it requires information to indicate to all
other leaves that the packet must be discarded. To address a packet 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 to an intermediate node in the tree, Time-to-Live-based addressing is
set the radius and additional information in the OAM payload is used used to set the radius and additional information in the OAM payload
to identify the specific destination. It is worth noting that a MIP is used to identify the specific destination. It is worth noting
and MEP may be instantiated on a single node when it is both a branch that a MIP and MEP may be instantiated on a single node when it is
and leaf node. both a branch and leaf 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].
A more detailed discussion of P2MP OAM considerations can be found in A more detailed discussion of P2MP OAM considerations can be found in
[I-D.hmk-mpls-tp-p2mp-oam-framework]. [MPLS-TP-P2MP-OAM].
5. Control Plane 6. 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: control-plane requirements are:
o requirement 6 (P2MP transport paths), o requirement 6 (P2MP transport paths),
o requirement 34 (use P2P sub-layers), o requirement 34 (use P2P sub-layers),
o requirement 49 (common recovery solutions for P2P and P2MP), o requirement 49 (common recovery solutions for P2P and P2MP),
o requirement 59 (1+1 protection), o requirement 59 (1+1 protection),
o requirement 62 (1:n protection), o requirement 62 (1:n protection), and
o and requirement 65 (1:n shared mesh recovery). o requirement 65 (1:n shared mesh recovery).
[RFC6373] defines the control plane approach used to support MPLS-TP [RFC6373] defines the control-plane approach used to support MPLS-TP
transport paths. It identifies GMPLS as the control plane for MPLS- transport paths. It identifies GMPLS as the control plane for MPLS-
TP LSPs tLDP as the control plane for PWs. MPLS-TP allows that 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 either, or both, LSPs and PWs to be provisioned statically or via a
control plane. As noted in [RFC6373]: control plane. Quoting from [RFC6373]:
The PW and LSP control planes, collectively, must satisfy the MPLS-TP The PW and LSP control planes, collectively, must satisfy the
control-plane requirements. As with P2P services, when P2MP client MPLS-TP control-plane requirements. As with P2P services, when
services are provided directly via LSPs, all requirements must be P2MP client services are provided directly via LSPs, all
satisfied by the LSP control plane. When client services are requirements must be satisfied by the LSP control plane. When
provided via PWs, the PW and LSP control planes can operate in client services are provided via PWs, the PW and LSP control
combination, and some functions may be satisfied via the PW control planes can operate in combination, and some functions may be
plane while others are provided to PWs by the LSP control plane. satisfied via the PW control plane while others are provided to
This is particularly noteworthy for P2MP recovery. PWs by the LSP control plane. This is particularly noteworthy for
P2MP recovery.
5.1. P2MP LSP Control Plane 6.1. P2MP LSP Control Plane
The MPLS-TP control plane for P2MP LSPs uses GMPLS and is based on The MPLS-TP control plane for P2MP LSPs uses GMPLS and is based on
RSVP-TE for P2MP LSPs as defined in [RFC4875]. A detailed listing of RSVP-TE for P2MP LSPs as defined in [RFC4875]. A detailed listing of
how GMPLS satisfies MPLS-TP control plane requirements is provided in how GMPLS satisfies MPLS-TP control-plane requirements is provided in
[RFC6373]. [RFC6373].
[RFC6373]notes that recovery techniques for Traffic Engineered P2MP [RFC6373] notes that recovery techniques for traffic engineered P2MP
LSPs are not formally defined, and such that a definition is needed. LSPs are not formally defined, and that such a definition is needed.
A formal definition will be based on existing RFCs and may not A formal definition will be based on existing RFCs and may not
require any new protocol mechanisms but, nonetheless, should be require any new protocol mechanisms but, nonetheless, should be
documented. GMPLS recovery is defined in [RFC4872] and [RFC4873]. documented. GMPLS recovery is defined in [RFC4872] and [RFC4873].
Protection of P2MP LSPs is also discussed in [RFC6372] Section 4.7.3. Protection of P2MP LSPs is also discussed in [RFC6372] Section 4.7.3.
5.2. P2MP PW Control Plane 6.2. P2MP PW Control Plane
The MPLS-TP control plane for P2MP PWs should be based on the LDP The MPLS-TP control plane for P2MP PWs should be based on the LDP
control protocol used for point-to-point PWs [RFC4447], with updates control protocol used for point-to-point PWs [RFC4447], with updates
as required for P2MP applications. A detailed specification of the as required for P2MP applications. A detailed specification of the
control plane for P2MP PWs is for further study. control plane for P2MP PWs is for further study.
6. Survivability 7. 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 of that RFC in particular describes the
of linear protection to unidirectional P2MP entities using 1+1 and application of linear protection to unidirectional P2MP entities
1:1 protection architecture. For 1+1, the approach is for the root using 1+1 and 1:1 protection architecture. For 1+1, the approach is
of the P2MP tree to bridge the user traffic to both the working and for the root of the P2MP tree to bridge the user traffic to both the
protection entities. Each sink/leaf MPLS-TP node selects the traffic working and protection entities. Each sink/leaf MPLS-TP node selects
from one entity according to some predetermined criteria. For 1:1, the traffic from one entity according to some predetermined criteria.
the source/root MPLS-TP node needs to identify the existence of a For 1:1, the source/root MPLS-TP node needs to identify the existence
fault condition impacting delivery to any of the leaves. Fault of a fault condition impacting delivery to any of the leaves. Fault
notification happens from the node identifying the fault to the root notification happens from the node identifying the fault to the root
node via an out of band path. The root then selects the protection node via an out-of-band path. The root then selects the protection
transport path for traffic transfer. More sophisticated transport path for traffic transfer. More sophisticated
survivability approaches such as partial tree protection and 1:n survivability approaches such as partial tree protection and 1:n
protection are for further study. 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;
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 8. Network Management
An overview of network management considerations for MPLS-TP can be An overview of network management considerations for MPLS-TP can be
found in Section 3.14 of "Framework for MPLS in Transport Networks" found in Section 3.14 of [RFC5921]. The provided description applies
[RFC5921]. The provided description applies equally to P2MP equally to P2MP transport paths.
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. [RFC5951] covers all MPLS-TP connection types, including P2MP.
[RFC6639] provides the MIB-based architecture for MPLS-TP. It [RFC6639] provides the MIB-based architecture for MPLS-TP. It
reviews the interrelationships between different non MPLS-TP specific reviews the interrelationships between different MIB modules that are
MIB modules that can be leveraged for MPLS-TP network management, and not MPLS-TP specific and that can be leveraged for MPLS-TP network
identifies areas where additional MIB modules are required. While management, and identifies areas where additional MIB modules are
the document does not consider P2MP transport paths, it does provide required. While the document does not consider P2MP transport paths,
a foundation for an analysis of areas where MIB module modification it does provide a foundation for an analysis of areas where MIB-
and addition may be needed to fully support P2MP transport paths. module modification and addition may be needed to fully support P2MP
There has also been work in the MPLS working group on a P2MP specific transport paths. There has also been work in the MPLS working group
MIB, [I-D.ietf-mpls-p2mp-te-mib]. on a P2MP specific MIB, [MPLS-TE-P2MP-MIB].
8. Security Considerations 9. 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 P2MP LSPs are provided in Additional security considerations for P2MP LSPs are provided in
[RFC4875]. This document introduces no new security considerations [RFC4875]. This document introduces no new security considerations
beyond those covered in those documents. beyond those covered in those documents.
9. IANA Considerations
There are no requests for IANA actions in this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi- Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, May Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
2007. 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
skipping to change at page 10, line 7 skipping to change at page 10, line 18
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile", and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009. RFC 5654, September 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010. 5921, July 2010.
10.2. Informative References 10.2. Informative References
[G.7710] ITU-T Recommendation G.7710/Y.1701 (07/2007), "Common [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
equipment management function requirements", 2007. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 [G.7710] ITU-T, "Common equipment management function
optical transport network hierarchy equipment functional requirements", ITU-T G.7710/Y.1701, July 2007.
blocks", 2010.
[I-D.hmk-mpls-tp-p2mp-oam-framework] [G.780] ITU-T, "Terms and definitions for synchronous digital
Koike, Y., Hamano, T., and M. Namiki, "Framework for hierarchy (SDH) networks", ITU-T G.780/Y.1351, July 2010.
Point-to-Multipoint MPLS-TP OAM", draft-hmk-mpls-tp-p2mp-
oam-framework-03 (work in progress), October 2013.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] [G.798] ITU-T, "Characteristics of optical transport network
Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., hierarchy equipment functional blocks", ITU-T G.798,
and L. Jin, "Framework and Requirements for Virtual December 2012.
Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms-
frmwk-requirements-05 (work in progress), October 2012.
[I-D.ietf-mpls-p2mp-te-mib] [MPLS-TE-P2MP-MIB]
Farrel, A., Yasukawa, S., and T. Nadeau, "Point-to- Farrel, A., Yasukawa, S., and T. Nadeau, "Point-to-
Multipoint Multiprotocol Label Switching (MPLS) Traffic Multipoint Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB) Engineering (TE) Management Information Base (MIB)
module", draft-ietf-mpls-p2mp-te-mib-09 (work in module", Work in Progress, April 2009.
progress), April 2009.
[I-D.ietf-pwe3-p2mp-pw-requirements] [MPLS-TP-P2MP-OAM]
JOUNAY, F., Kamite, Y., Heron, G., and M. Bocci, Arai, K., Koike, Y., Hamano, T., and M. Namiki, "Framework
"Requirements and Framework for Point-to-Multipoint for Point-to-Multipoint MPLS-TP OAM", Work in Progress,
Pseudowires over MPLS PSNs", draft-ietf-pwe3-p2mp-pw- January 2014.
requirements-06 (work in progress), October 2013.
[I-D.raggarwa-pwe3-p2mp-pw-encaps] [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", Work in Progress, March 2010.
(work in progress), March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [P2MP-PW-REQS]
Requirement Levels", BCP 14, RFC 2119, March 1997. Jounay, F., Kamite, Y., Heron, G., and M. Bocci,
"Requirements and Framework for Point-to-Multipoint
Pseudowires over MPLS PSNs", Work in Progress, February
2014.
[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. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006. Distribution Protocol (LDP)", RFC 4447, April 2006.
skipping to change at page 11, line 37 skipping to change at page 11, line 37
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 [RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label Switching
Transport Profile (MPLS-TP) MIB-Based Management Transport Profile (MPLS-TP) MIB-Based Management
Overview", RFC 6639, June 2012. Overview", RFC 6639, June 2012.
[VPMS-FRMWK-REQS]
Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", Work in Progress,
October 2012.
Authors' Addresses Authors' Addresses
Dan Frost Dan Frost
Blue Sun Blue Sun
EMail: frost@mm.st EMail: frost@mm.st
Stewart Bryant Stewart Bryant
Cisco Systems Cisco Systems
 End of changes. 58 change blocks. 
160 lines changed or deleted 145 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/