draft-ietf-mpls-tp-p2mp-framework-04.txt   draft-ietf-mpls-tp-p2mp-framework-05.txt 
MPLS Working Group D. Frost MPLS Working Group D. Frost
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: April 14, 2014 M. Bocci Expires: May 22, 2014 M. Bocci
Alcatel-Lucent Alcatel-Lucent
L. Berger L. Berger
LabN Consulting LabN Consulting
October 14, 2013 November 18, 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-04 draft-ietf-mpls-tp-p2mp-framework-05
Abstract Abstract
The Multiprotocol Label Switching Transport Profile is the common set The Multiprotocol Label Switching Transport Profile is the common set
of MPLS protocol functions defined to enable the construction and of MPLS protocol functions defined to enable the construction and
operation of packet transport networks. The MPLS-TP supports both operation of packet transport networks. The MPLS-TP supports both
point-to-point and point-to-multipoint transport paths. This point-to-point and point-to-multipoint transport paths. 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.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 14, 2014. This Internet-Draft will expire on May 22, 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 5 3.1. MPLS-TP Encapsulation and Forwarding . . . . . . . . . . 6
4. Operations, Administration and Maintenance . . . . . . . . . 5 4. Operations, Administration and Maintenance . . . . . . . . . 6
5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 6 5.1. Point-to-Multipoint LSP Control Plane . . . . . . . . . . 7
5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . 7 5.2. Point-to-Multipoint PW Control Plane . . . . . . . . . . 8
6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Network Management . . . . . . . . . . . . . . . . . . . . . 7 7. Network Management . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Multiprotocol Label Switching Transport Profile is the common set The Multiprotocol Label Switching Transport Profile is the common set
of MPLS protocol functions defined to meet the requirements specified of MPLS protocol functions defined to meet the requirements specified
in [RFC5654]. The MPLS-TP Framework [RFC5921] provides an overall in [RFC5654]. The MPLS-TP Framework [RFC5921] provides an overall
introduction to the MPLS-TP and defines the general architecture of introduction to the MPLS-TP and defines the general architecture of
the Transport Profile, as well as those aspects specific to point-to- the Transport Profile, as well as those aspects specific to point-to-
point transport paths. The purpose of this document is to define the point transport paths. The purpose of this document is to define the
elements and functions of the MPLS-TP architecture applicable elements and functions of the MPLS-TP architecture applicable
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1.2. Terminology 1.2. Terminology
Term Definition Term Definition
------- --------------------------------------------------- ------- ---------------------------------------------------
CE Customer Edge CE Customer Edge
GMPLS Generalized MPLS GMPLS Generalized MPLS
LDP Label Distribution Protocol LDP Label Distribution Protocol
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
MEP Maintenance End Point MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point
MPLS Multiprotocol Label Switching MPLS Multiprotocol Label Switching
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
T-LDP Targeted LDP tLDP 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
skipping to change at page 4, line 15 skipping to change at page 4, line 10
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. This summary does not include the complete list of requirements. This summary does not include the
[RFC2119] conformance language used in original documents as this [RFC2119] conformance language used in original documents as this
document is not authoritative. document is not authoritative.
o MPLS-TP must support unidirectional point-to-multipoint transport From [RFC5654]:
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 support unidirectional point-to-multipoint 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.,
unidirectional P2P, associated bidirectional P2P, co-routed unidirectional P2P, associated bidirectional P2P, co-routed
bidirectional P2P, unidirectional P2MP) including configuration of bidirectional P2P, unidirectional P2MP) including configuration of
protection functions and any associated maintenance functions. protection functions and any associated maintenance functions.
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.
From [RFC5860]:
o 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
o 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 [RFC5951]:
o For unidirectional (P2P and point-to-multipoint (P2MP))
connection, proactive measurement of packet loss and loss ratio is
required.
o For a unidirectional (P2P and P2MP) connection, on-demand
measurement of delay measurement is required.
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 LSPs o Unidirectional point-to-multipoint LSPs
o Unidirectional point-to-multipoint PWs o Unidirectional point-to-multipoint PWs
skipping to change at page 5, line 28 skipping to change at page 6, line 26
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
[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 4. Operations, Administration and Maintenance
The overall OAM architecture for MPLS-TP is defined in [RFC6371], and The requirements for MPLS-TP OAM are specified in [RFC5860]. 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 towards
the leaves, thus every OAM packet is sent to all leaves, and thus can all the leaves, and thus may be processed by all the MIPs and MEPs
impact all the MEs in a P2MP MEG. If an OAM packet is to be associated with a P2MP MEG. If an OAM packet is to be processed by
processed by only a specific leaf, it requires information to only a specific leaf, it requires information to indicate to all
indicate to all other leaves that the packet must be discarded. To other leaves that the packet must be discarded. To address a packet
address a packet to an intermediate node in the tree, TTL based to an intermediate node in the tree, TTL based addressing is used to
addressing is used to set the radius and addressing information in set the radius and additional information in the OAM payload is used
the OAM payload is used to identify the specific destination node. 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 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
considers the P2MP case and no change is needed to the MPLS-TP
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: 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),
skipping to change at page 6, line 28 skipping to change at page 7, line 25
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),
o and requirement 65 (1:n shared mesh recovery). 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 GMPLS as the control plane for MPLS- transport paths. It identifies GMPLS as the control plane for MPLS-
TP LSPs T-LDP as the control plane for PWs. MPLS-TP allows that TP LSPs 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. 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.
skipping to change at page 7, line 24 skipping to change at page 8, line 22
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,
the source/root MPLS-TP node needs to identify the existence of a the source/root MPLS-TP node needs to identify the existence of a
fault condition on any of the branches of the network. Fault 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 and from the leaves to the root via an out of band path. In node via an out of band path. The root then selects the protection
either case the root then selects the protection transport path for transport path for traffic transfer. More sophisticated
traffic transfer. More sophisticated survivability approaches such survivability approaches such as partial tree protection and 1:n
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, and
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 7. Network Management
An overview of network management considerations for MPLS-TP can be An overview of network management considerations for MPLS-TP can be
skipping to change at page 9, line 5 skipping to change at page 10, line 5
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.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay
Measurement Profile for MPLS-Based Transport Networks",
RFC 6375, September 2011.
10.2. Informative References 10.2. Informative References
[G.7710] ITU-T Recommendation G.7710/Y.1701 (07/2007), "Common [G.7710] ITU-T Recommendation G.7710/Y.1701 (07/2007), "Common
equipment management function requirements", 2007. equipment management function requirements", 2007.
[G.780] ITU-T Recommendation G.780//Y.1351 (07/2010), "Terms and [G.780] ITU-T Recommendation G.780//Y.1351 (07/2010), "Terms and
definitions for synchronous digital hierarchy (SDH) definitions for synchronous digital hierarchy (SDH)
networks", 2010. networks", 2010.
[G.798] ITU-T Recommendation G.798 (10/2010), "Characteristics of [G.798] ITU-T Recommendation G.798 (10/2010), "Characteristics of
optical transport network hierarchy equipment functional optical transport network hierarchy equipment functional
blocks", 2010. blocks", 2010.
[I-D.hmk-mpls-tp-p2mp-oam-framework] [I-D.hmk-mpls-tp-p2mp-oam-framework]
Koike, Y., Hamano, T., and M. Namiki, "Framework for Koike, Y., Hamano, T., and M. Namiki, "Framework for
Point-to-Multipoint MPLS-TP OAM", draft-hmk-mpls-tp-p2mp- Point-to-Multipoint MPLS-TP OAM", draft-hmk-mpls-tp-p2mp-
oam-framework-02 (work in progress), February 2013. oam-framework-03 (work in progress), October 2013.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] [I-D.ietf-l2vpn-vpms-frmwk-requirements]
Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D.,
and L. Jin, "Framework and Requirements for Virtual and L. Jin, "Framework and Requirements for Virtual
Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms- Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms-
frmwk-requirements-05 (work in progress), October 2012. frmwk-requirements-05 (work in progress), October 2012.
[I-D.ietf-mpls-p2mp-te-mib] [I-D.ietf-mpls-p2mp-te-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", 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 JOUNAY, F., Kamite, Y., Heron, G., and M. Bocci,
Framework for Point-to-Multipoint Pseudowires over MPLS "Requirements and Framework for Point-to-Multipoint
PSNs", draft-ietf-pwe3-p2mp-pw-requirements-05 (work in Pseudowires over MPLS PSNs", draft-ietf-pwe3-p2mp-pw-
progress), September 2011. requirements-06 (work in progress), October 2013.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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.
 End of changes. 21 change blocks. 
53 lines changed or deleted 92 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/