draft-ietf-mpls-tp-p2mp-framework-03.txt   draft-ietf-mpls-tp-p2mp-framework-04.txt 
MPLS Working Group D. Frost, Ed. MPLS Working Group D. Frost
Internet-Draft S. Bryant, Ed. Internet-Draft S. Bryant
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: April 11, 2014 M. Bocci, Ed. Expires: April 14, 2014 M. Bocci
Alcatel-Lucent Alcatel-Lucent
L. Berger, Ed. L. Berger
LabN Consulting LabN Consulting
October 11, 2013 October 14, 2013
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-03 draft-ietf-mpls-tp-p2mp-framework-04
Abstract Abstract
The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) The Multiprotocol Label Switching Transport Profile is the common set
is the common set of MPLS protocol functions defined to enable the of MPLS protocol functions defined to enable the construction and
construction and operation of packet transport networks. The MPLS-TP operation of packet transport networks. The MPLS-TP supports both
supports both point-to-point and point-to-multipoint transport paths. point-to-point and point-to-multipoint transport paths. This
This document defines the elements and functions of the MPLS-TP document defines 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.
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 functions of a packet transport network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2014. This Internet-Draft will expire on April 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 20 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Additional Definitions and Terminology . . . . . . . 3 1.2.1. Additional Definitions and Terminology . . . . . . . 3
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. MPLS Transport Profile Point-to-Multipoint Requirements . . . 4 2. MPLS Transport Profile Point-to-Multipoint Requirements . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 5 3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 5
4. Operations, Administration and Maintenance (OAM) . . . . . . 5 4. Operations, Administration and Maintenance . . . . . . . . . 5
5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 7 5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 6
5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . 7 5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . 7
6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Network Management . . . . . . . . . . . . . . . . . . . . . 8 7. Network Management . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) The Multiprotocol Label Switching Transport Profile is the common set
is the common set of MPLS protocol functions defined to meet the of MPLS protocol functions defined to meet the requirements specified
requirements specified in [RFC5654]. The MPLS-TP Framework [RFC5921] in [RFC5654]. The MPLS-TP Framework [RFC5921] provides an overall
provides an overall introduction to the MPLS-TP and defines the introduction to the MPLS-TP and defines the general architecture of
general architecture of the Transport Profile, as well as those the Transport Profile, as well as those aspects specific to point-to-
aspects specific to point-to-point transport paths. The purpose of point transport paths. The purpose of this document is to define the
this document is to define the elements and functions of the MPLS-TP elements and functions of the MPLS-TP architecture applicable
architecture applicable specifically to supporting point-to- specifically to supporting point-to-multipoint transport paths.
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 functions of a packet transport network.
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 those aspects of the
MPLS-TP architecture that are generic, or concerned specifically with MPLS-TP architecture that are generic, or concerned specifically with
point-to-point transport paths. point-to-point transport paths.
1.2. Terminology 1.2. Terminology
Term Definition Term Definition
------- ------------------------------------------ ------- ---------------------------------------------------
CE Customer Edge
GMPLS Generalized MPLS
LDP Label Distribution Protocol
LSP Label Switched Path 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 LSR Label Switching Router
MEP Maintenance End Point
MPLS Multiprotocol Label Switching
MPLS-TE MPLS Traffic Engineering MPLS-TE MPLS Traffic Engineering
MPLS-TP MPLS Transport Profile
OAM Operations, Administration and Maintenance
OTN Optical Transport Network
P2MP Point-to-multipoint P2MP Point-to-multipoint
PW Pseudowire PW Pseudowire
RSVP-TE Resource Reservation Protocol - Traffic Engineering
SDH Synchronous Digital Hierarchy
T-LDP Targeted LDP
1.2.1. Additional Definitions and Terminology 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 1.3. 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. P2MP MPLS TE-LSP support is discussed in [RFC4875] and networks. P2MP MPLS TE-LSP support is discussed in [RFC4875] and
[RFC5332], and P2MP PW support is being developed based on [RFC5332], and P2MP PW support is being developed based on
[I-D.ietf-pwe3-p2mp-pw-requirements] and [I-D.ietf-pwe3-p2mp-pw-requirements] and
[I-D.ietf-l2vpn-vpms-frmwk-requirements]. MPLS-TP point-to- [I-D.ietf-l2vpn-vpms-frmwk-requirements]. MPLS-TP point-to-
multipoint connectivity is analogous to that provided by traditional multipoint connectivity is analogous to that provided by traditional
transport technologies such as Optical Transport Network (OTN) point- transport technologies such as Optical Transport Network point-to-
to-multipoint [G.798] and drop-and-continue [G.780], and thus multipoint [G.798] and drop-and-continue [G.780], and thus supports
supports the same class of traditional applications, e.g., video the same class of traditional applications, e.g., video distribution.
distribution.
There is no definition for MPLS TE-LSP support of multipoint-to-
multipoint connectivity and none is anticipated.
2. MPLS Transport Profile Point-to-Multipoint Requirements 2. MPLS Transport Profile Point-to-Multipoint 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. 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 (P2MP) o MPLS-TP must support unidirectional point-to-multipoint transport
transport paths. paths.
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 be capable of using P2MP server (sub)layer o MPLS-TP must be capable of using P2MP server (sub)layer
capabilities as well as P2P server (sub)layer capabilities when capabilities as well as P2P server (sub)layer capabilities when
supporting P2MP MPLS-TP transport paths. supporting P2MP MPLS-TP transport paths.
o The MPLS-TP control plane must support establishing all the o The MPLS-TP control plane must support establishing all the
connectivity patterns defined for the MPLS-TP data plane (i.e., connectivity patterns defined for the MPLS-TP data plane (i.e.,
skipping to change at page 5, line 4 skipping to change at page 4, line 41
o Recovery techniques used for P2P and P2MP should be identical to o Recovery techniques used for P2P and P2MP should be identical to
simplify implementation and operation. simplify implementation and operation.
o Unidirectional 1+1 and 1:n protection for P2MP connectivity must o Unidirectional 1+1 and 1:n protection for P2MP connectivity must
be supported. be supported.
o MPLS-TP recovery in a ring must protect unidirectional P2MP o MPLS-TP recovery in a ring must protect unidirectional P2MP
transport paths. transport paths.
3. Architecture 3. Architecture
The overall architecture of the MPLS Transport Profile is defined in The overall architecture of the MPLS Transport Profile is defined in
[RFC5921]. The architecture for point-to-multipoint MPLS-TP [RFC5921]. The architecture for point-to-multipoint MPLS-TP
comprises the following additional elements and functions: comprises the following additional elements and functions:
o Unidirectional point-to-multipoint Label Switched Paths (LSPs) o Unidirectional point-to-multipoint LSPs
o Unidirectional point-to-multipoint pseudowires (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 (OAM) functions for point-to-multipoint PWs and and Maintenance functions for point-to-multipoint PWs and LSPs
LSPs
The following subsections summarise the encapsulation and forwarding The following subsections summarise 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 encapsulation options for delivery of traffic to and from MPLS-TP CE
Customer Edge devices when the network is providing a packet devices when the network is providing a packet transport service.
transport service.
3.1. MPLS-TP Encapsulation and Forwarding 3.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 by the PWE3 Working Group been discussed within the PWE3 Working Group
[I-D.raggarwa-pwe3-p2mp-pw-encaps], but such definition is for [I-D.raggarwa-pwe3-p2mp-pw-encaps], but such definition is for
further study. further study.
4. Operations, Administration and Maintenance (OAM) 4. Operations, Administration and Maintenance
The overall OAM architecture for MPLS-TP is defined in [RFC6371], and The 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 to all 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 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 impact all the MEs in a P2MP MEG. If an OAM packet is to be
packet is to be processed by only one leaf, it requires information processed by only a specific leaf, it requires information to
to indicate to all other leaves that the packet must be discarded. indicate to all other leaves that the packet must be discarded. To
To address a packet to an intermediate node in the tree, TTL based address a packet to an intermediate node in the tree, TTL based
addressing is used to set the radius and addressing information in addressing is used to set the radius and addressing information in
the OAM payload is used to identify the specific destination node. the OAM payload is used to identify the specific destination 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].
Packet Loss and Delay Measurement for MPLS Networks [RFC6374] already Packet Loss and Delay Measurement for MPLS Networks [RFC6374] already
considers the P2MP case and it is not thought that any change is considers the P2MP case and no change is needed to the MPLS-TP
needed to the MPLS-TP profile of [RFC6375]. profile of [RFC6375].
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]. [I-D.hmk-mpls-tp-p2mp-oam-framework].
5. Control Plane 5. 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 identified in requirement 6 (P2MP control plane requirements are:
transport paths), 34 (use P2P sub-layers), 49 (common recovery
solutions for P2P and P2MP), 59 (1+1 protection), 62 (1:n o requirement 6 (P2MP transport paths),
protection), and 65 (1:n shared mesh recovery).
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 [RFC6373] defines the control plane approach used to support MPLS-TP
transport paths. It identifies Generalized MPLS (GMPLS) as the transport paths. It identifies GMPLS as the control plane for MPLS-
control plane for MPLS-TP Label Switched Paths (LSPs) and Targeted TP LSPs T-LDP as the control plane for PWs. MPLS-TP allows that
LDP (T-LDP) as the control plane for pseudowires (PWs). MPLS-TP either, or both, LSPs and PWs to be provisioned statically or via a
allows that either, or both, LSPs and PWs to be provisioned control plane. As noted in [RFC6373]:
statically or via a control plane. As noted in [RFC6373]:
The PW and LSP control planes, collectively, must satisfy the MPLS-TP The PW and LSP control planes, collectively, must satisfy the MPLS-TP
control-plane requirements. As with P2P services, when P2MP client control-plane requirements. As with P2P services, when P2MP client
services are provided directly via LSPs, all requirements must be services are provided directly via LSPs, all requirements must be
satisfied by the LSP control plane. When client services are satisfied by the LSP control plane. When client services are
provided via PWs, the PW and LSP control planes can operate in provided via PWs, the PW and LSP control planes can operate in
combination, and some functions may be satisfied via the PW control combination, and some functions may be satisfied via the PW control
plane while others are provided to PWs by the LSP control plane. plane while others are provided to PWs by the LSP control plane.
This is particularly noteworthy for P2MP recovery. This is particularly noteworthy for P2MP recovery.
5.1. Point-to-Multipoint LSP Control Plane 5.1. Point-to-Multipoint LSP Control Plane
The MPLS-TP control plane for point-to-multipoint LSPs uses GMPLS and The MPLS-TP control plane for point-to-multipoint LSPs uses GMPLS and
is based on Resource Reservation Protocol - Traffic Engineering is based on RSVP-TE for point-to-multipoint LSPs as defined in
(RSVP-TE) for point-to-multipoint LSPs as defined in [RFC4875]. A [RFC4875]. A detailed listing of how GMPLS satisfies MPLS-TP control
detailed listing of how GMPLS satisfies MPLS-TP control plane plane requirements is provided in [RFC6373].
requirements is provided in [RFC6373].
Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS
recovery, [RFC4872] and [RFC4873], do not explicitly cover their recovery, [RFC4872] and [RFC4873], do not explicitly cover their
interactions. MPLS-TP requires a formal definition of recovery interactions. MPLS-TP requires a formal definition of recovery
techniques for P2MP LSPs. Such a formal definition will be based on techniques for P2MP LSPs. Such a formal definition will be based on
existing RFCs and may not require any new protocol mechanisms but, existing RFCs and may not require any new protocol mechanisms but,
nonetheless, should be documented. Protection of P2MP LSPs is also nonetheless, should be documented. Protection of P2MP LSPs is also
discussed in [RFC6372] Section 4.7.3. discussed in [RFC6372] Section 4.7.3.
5.2. Point-to-Multipoint PW Control Plane 5.2. Point-to-Multipoint PW Control Plane
The MPLS-TP control plane for point-to-multipoint PWs should be based 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], on the LDP control protocol used for point-to-point PWs [RFC4447],
with updates as required for P2MP applications. A detailed with updates as required for P2MP applications. A detailed
specification of the > control plane for P2MP PWs is for further specification of the control plane for P2MP PWs is for further study.
study.
6. Survivability 6. 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 in particular describes the application
of linear protection to unidirectional P2MP entities using 1+1 and of linear protection to unidirectional P2MP entities using 1+1 and
1:1 protection architecture. For 1+1, the approach is for the root 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 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 protection entities. Each sink/leaf MPLS-TP node selects the traffic
from one entity according to some predetermined criteria. For 1:1, from one entity according to some predetermined criteria. For 1:1,
skipping to change at page 8, line 40 skipping to change at page 8, line 24
8. Security Considerations 8. 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 point-to-multipoint LSPs are Additional security considerations for point-to-multipoint LSPs are
provided in [RFC4875]. This document introduces no new security provided in [RFC4875]. This document introduces no new security
considerations beyond those covered in those documents. considerations beyond those covered in those documents.
9. IANA Considerations 9. IANA Considerations
IANA considerations resulting from specific elements of MPLS-TP There are no requests for IANA actions in this document.
functionality are detailed in the documents specifying that
functionality. This document introduces no additional IANA
considerations in itself.
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,
"GMPLS Segment Recovery", RFC 4873, May 2007. "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[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 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. Multicast Encapsulations", RFC 5332, August 2008.
[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.
skipping to change at page 10, line 27 skipping to change at page 9, line 49
Engineering (TE) Management Information Base (MIB) Engineering (TE) Management Information Base (MIB)
module", draft-ietf-mpls-p2mp-te-mib-09 (work in module", draft-ietf-mpls-p2mp-te-mib-09 (work in
progress), April 2009. progress), April 2009.
[I-D.ietf-pwe3-p2mp-pw-requirements] [I-D.ietf-pwe3-p2mp-pw-requirements]
Bocci, M., Heron, G., and Y. Kamite, "Requirements and Bocci, M., Heron, G., and Y. Kamite, "Requirements and
Framework for Point-to-Multipoint Pseudowires over MPLS Framework for Point-to-Multipoint Pseudowires over MPLS
PSNs", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in PSNs", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in
progress), September 2011. progress), September 2011.
[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.raggarwa-pwe3-p2mp-pw-encaps] [I-D.raggarwa-pwe3-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", draft-raggarwa-pwe3-p2mp-pw-encaps-01
(work in progress), March 2010. (work in progress), March 2010.
[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. [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.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
skipping to change at page 11, line 24 skipping to change at page 10, line 40
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.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire
Redundancy", RFC 6718, August 2012.
Authors' Addresses Authors' Addresses
Dan Frost (editor) Dan Frost
Cisco Systems Cisco Systems
EMail: danfrost@cisco.com EMail: danfrost@cisco.com
Stewart Bryant (editor) Stewart Bryant
Cisco Systems Cisco Systems
EMail: stbryant@cisco.com EMail: stbryant@cisco.com
Matthew Bocci
Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Voyager Place, Shoppenhangers Road Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ Maidenhead, Berks SL6 2PJ
United Kingdom United Kingdom
EMail: matthew.bocci@alcatel-lucent.com EMail: matthew.bocci@alcatel-lucent.com
Lou Berger (editor)
Lou Berger
LabN Consulting LabN Consulting
Phone: +1-301-468-9228 Phone: +1-301-468-9228
EMail: lberger@labn.net EMail: lberger@labn.net
 End of changes. 46 change blocks. 
116 lines changed or deleted 93 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/