< draft-ietf-pals-rfc4447bis-03.txt   draft-ietf-pals-rfc4447bis-05.txt >
Internet Engineering Task Force Luca Martini Ed. Internet Engineering Task Force Luca Martini Ed.
Internet Draft Giles Heron Ed. Internet Draft Giles Heron Ed.
Intended status: Internet Standard Intended status: Internet Standard
Expires: August 4, 2016 Cisco Expires: January 5, 2017 Cisco
Obsoletes: 6723, 4447
February 4, 2016 July 5, 2016
Pseudowire Setup and Maintenance using the Label Distribution Protocol Pseudowire Setup and Maintenance using the Label Distribution Protocol
draft-ietf-pals-rfc4447bis-03.txt draft-ietf-pals-rfc4447bis-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 4, 2016 This Internet-Draft will expire on January 5, 2016
Abstract Abstract
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode,
and Ethernet) can be "emulated" over an MPLS backbone by and Ethernet) can be "emulated" over an MPLS backbone by
encapsulating the Layer 2 Protocol Data Units (PDU) and then encapsulating the Layer 2 Protocol Data Units (PDU) and then
transmitting them over "pseudowires". It is also possible to use transmitting them over "pseudowires". It is also possible to use
pseudowires to provide low-rate Time Division Multiplexed and pseudowires to provide low-rate Time Division Multiplexed and
Synchronous Optical NETworking circuit emulation over an MPLS-enabled Synchronous Optical NETworking circuit emulation over an MPLS-enabled
network. This document specifies a protocol for establishing and network. This document specifies a protocol for establishing and
maintaining the pseudowires, using extensions to the Label maintaining the pseudowires, using extensions to the Label
Distribution Protocol (LDP). Procedures for encapsulating Layer 2 Distribution Protocol (LDP). Procedures for encapsulating Layer 2
PDUs are specified in a set of companion documents. PDUs are specified in a set of companion documents.
This document has been written to address errata in a previous This document has been written to address errata in a previous
version of this standard. version of this standard.
Table of Contents Table of Contents
1 Changes from RFC4447 ................................. 4 1 Introduction ......................................... 4
2 Introduction ......................................... 4 2 Changes from RFC4447 ................................. 6
3 Specification of Requirements ........................ 7 3 Specification of Requirements ........................ 7
4 The Pseudowire Label ................................. 7 4 The Pseudowire Label ................................. 7
5 Details Specific to Particular Emulated Services ..... 9 5 Details Specific to Particular Emulated Services ..... 9
5.1 IP Layer 2 Transport ................................. 9 5.1 IP Layer 2 Transport ................................. 9
6 LDP .................................................. 9 6 LDP .................................................. 9
6.1 The PWid FEC Element ................................. 10 6.1 The PWid FEC Element ................................. 10
6.2 The Generalized PWid FEC Element ..................... 11 6.2 The Generalized PWid FEC Element ..................... 11
6.2.1 Attachment Identifiers ............................... 12 6.2.1 Attachment Identifiers ............................... 12
6.2.2 Encoding the Generalized PWid FEC Element ............ 13 6.2.2 Encoding the Generalized PWid FEC Element ............ 13
6.2.2.1 Interface Parameters TLV ............................. 15 6.2.2.1 Interface Parameters TLV ............................. 15
6.2.2.2 PW Grouping ID TLV ................................... 15 6.2.2.2 PW Group ID TLV ...................................... 15
6.2.3 Signaling Procedures ................................. 16 6.2.3 Signaling Procedures ................................. 16
6.3 Signaling of Pseudowire Status ....................... 17 6.3 Signaling of Pseudowire Status ....................... 17
6.3.1 Use of Label Mapping Messages ........................ 17 6.3.1 Use of Label Mapping Messages ........................ 17
6.3.2 Signaling PW Status .................................. 17 6.3.2 Signaling PW Status .................................. 17
6.3.3 Pseudowire Status Negotiation Procedures ............. 19 6.3.3 Pseudowire Status Negotiation Procedures ............. 19
6.4 Interface Parameters Sub-TLV ......................... 21 6.4 Interface Parameters Sub-TLV ......................... 21
6.5 LDP label Withdrawal procedures ...................... 22 6.5 LDP label Withdrawal procedures ...................... 22
7 Control Word ......................................... 22 7 Control Word ......................................... 22
7.1 PW Types for which the Control Word is REQUIRED ...... 22 7.1 PW Types for which the Control Word is REQUIRED ...... 22
7.2 PW Types for which the Control Word is NOT mandatory . 22 7.2 PW Types for which the Control Word is NOT mandatory . 22
7.3 Control-Word Renegotiation by Label Request Message .. 24 7.3 Control-Word Renegotiation by Label Request Message .. 24
7.4 Sequencing Considerations ............................ 25 7.4 Sequencing Considerations ............................ 25
7.4.1 Label Advertisements ................................. 25 7.4.1 Label Advertisements ................................. 25
7.4.2 Label Release ........................................ 25 7.4.2 Label Release ........................................ 25
8 IANA Considerations .................................. 26 8 IANA Considerations .................................. 26
8.1 LDP TLV TYPE ......................................... 26
8.2 LDP Status Codes ..................................... 26
8.3 FEC Type Name Space .................................. 26
9 Security Considerations .............................. 26 9 Security Considerations .............................. 26
9.1 Data-Plane Security .................................. 26 9.1 Data-Plane Security .................................. 26
9.2 Control-Plane Security ............................... 28 9.2 Control-Plane Security ............................... 27
10 Interoperability and Deployment ...................... 29 10 Interoperability and Deployment ...................... 28
11 Acknowledgments ...................................... 29 11 Acknowledgments ...................................... 29
12 Normative References ................................. 29 12 Normative References ................................. 29
13 Informative References ............................... 30 13 Informative References ............................... 29
14 Author Information ................................... 31 14 Author Information ................................... 31
15 Additional Historical Contributing Authors ........... 31 15 Additional Historical Contributing Authors ........... 31
1. Changes from RFC4447 1. Introduction
The changes in this document are mostly minor fixes to spelling and
grammar, or clarifications to the text, which were either noted as
errata to RFC4447 or found by the editors.
However a new section (6.3) on control-word renegotiation by label
request message has been added, obsoleting RFC 6723. The diagram of
C-bit handling procedures has also been removed. A note was added to
clarify that the C-bit is part of the FEC.
2. Introduction
[RFC4619], [RFC4717], [RFC4618], and [RFC4448] explain how to [RFC4619], [RFC4717], [RFC4618], and [RFC4448] explain how to
encapsulate a Layer 2 Protocol Data Unit (PDU) for transmission over encapsulate a Layer 2 Protocol Data Unit (PDU) for transmission over
an MPLS-enabled network. Those documents specify that a "pseudowire an MPLS-enabled network. Those documents specify that a "pseudowire
header", consisting of a demultiplexor field, will be prepended to header", consisting of a demultiplexor field, will be prepended to
the encapsulated PDU. The pseudowire demultiplexor field is the encapsulated PDU. The pseudowire demultiplexor field is
prepended before transmitting a packet on a pseudowire. When the prepended before transmitting a packet on a pseudowire. When the
packet arrives at the remote endpoint of the pseudowire, the packet arrives at the remote endpoint of the pseudowire, the
demultiplexor is what enables the receiver to identify the particular demultiplexor is what enables the receiver to identify the particular
pseudowire on which the packet has arrived. To transmit the packet pseudowire on which the packet has arrived. To transmit the packet
skipping to change at page 6, line 51 skipping to change at page 6, line 29
/ /
_____________/ _____________/
Figure 2: PWE3 Protocol Stack Reference Model Figure 2: PWE3 Protocol Stack Reference Model
For the purpose of this document, PE1 will be defined as the ingress For the purpose of this document, PE1 will be defined as the ingress
router, and PE2 as the egress router. A layer 2 PDU will be received router, and PE2 as the egress router. A layer 2 PDU will be received
at PE1, encapsulated at PE1, transported and decapsulated at PE2, and at PE1, encapsulated at PE1, transported and decapsulated at PE2, and
transmitted out of PE2. transmitted out of PE2.
Note that this document was written to address errata in [RFC4447]. 2. Changes from RFC4447
The changes in this document are mostly minor fixes to spelling and
grammar, or clarifications to the text, which were either noted as
errata to [RFC4447] or found by the editors.
Additionally a new section (7.3) on control-word renegotiation by
label request message has been added, obsoleting [RFC6723]. The
diagram of C-bit handling procedures has also been removed. A note
has been added in section 6.3.2 to clarify that the C-bit is part of
the FEC.
A reference has also been added to [RFC7358] indicating the use of
downstream unsolicited mode to distribute PW FEC label bindings,
independent of the negotiated label advertisement mode of the LDP
session.
3. Specification of Requirements 3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
4. The Pseudowire Label 4. The Pseudowire Label
Suppose that it is desired to transport Layer 2 PDUs from ingress LSR Suppose that it is desired to transport Layer 2 PDUs from ingress LSR
skipping to change at page 8, line 38 skipping to change at page 8, line 38
SHOULD be used. However all the LDP procedures that are specified in SHOULD be used. However all the LDP procedures that are specified in
[RFC5036], and that are also applicable to this protocol [RFC5036], and that are also applicable to this protocol
specification MUST be implemented. specification MUST be implemented.
This document requires that a receiving LSR MUST respond to a Label This document requires that a receiving LSR MUST respond to a Label
Request message with either a Label Mapping for the requested label Request message with either a Label Mapping for the requested label
or with a Notification message that indicates why it cannot satisfy or with a Notification message that indicates why it cannot satisfy
the request. These procedures are specified in [RFC5036] section the request. These procedures are specified in [RFC5036] section
3.5.7 "Label Mapping Message", and 3.5.8 "Label Request Message". 3.5.7 "Label Mapping Message", and 3.5.8 "Label Request Message".
Note that sending these responses is a stricter requirement than is Note that sending these responses is a stricter requirement than is
specified in RFC5036, but these response messages are REQUIRED to specified in [RFC5036] but these response messages are REQUIRED to
ensure correct operation of this protocol. ensure correct operation of this protocol.
In addition to the protocol specified herein, static assignment of PW In addition to the protocol specified herein, static assignment of PW
labels may be used, and implementations of this protocol SHOULD labels may be used, and implementations of this protocol SHOULD
provide support for static assignment. PW encapsulation is always provide support for static assignment. PW encapsulation is always
symmetrical in both directions of traffic along a specific PW, symmetrical in both directions of traffic along a specific PW,
whether the PW uses an LDP control plane or not. whether the PW uses an LDP control plane or not.
This document specifies all the procedures necessary to set up and This document specifies all the procedures necessary to set up and
maintain the pseudowires needed to support "unswitched" point to maintain the pseudowires needed to support "unswitched" point to
skipping to change at page 12, line 8 skipping to change at page 12, line 8
pair of endpoints. In addition, the endpoint identifiers are pair of endpoints. In addition, the endpoint identifiers are
structured to support applications where the identity of the remote structured to support applications where the identity of the remote
endpoints needs to be auto-discovered rather than statically endpoints needs to be auto-discovered rather than statically
configured. configured.
The "Generalized PWid FEC Element" is FEC type 0x81. The "Generalized PWid FEC Element" is FEC type 0x81.
The Generalized PWid FEC Element does not contain anything The Generalized PWid FEC Element does not contain anything
corresponding to the "Group ID" of the PWid FEC element. The corresponding to the "Group ID" of the PWid FEC element. The
functionality of the "Group ID" is provided by a separate optional functionality of the "Group ID" is provided by a separate optional
LDP TLV, the "PW Grouping TLV", described below. The Interface LDP TLV, the "PW Group ID TLV", described below. The Interface
Parameters field of the PWid FEC element is also absent; its Parameters field of the PWid FEC element is also absent; its
functionality is replaced by the optional Interface Parameters TLV, functionality is replaced by the optional Interface Parameters TLV,
described below. described below.
6.2.1. Attachment Identifiers 6.2.1. Attachment Identifiers
As discussed in [RFC3985], a pseudowire can be thought of as As discussed in [RFC3985], a pseudowire can be thought of as
connecting two "forwarders". The protocol used to set up a connecting two "forwarders". The protocol used to set up a
pseudowire must allow the forwarder at one end of a pseudowire to pseudowire must allow the forwarder at one end of a pseudowire to
identify the forwarder at the other end. We use the term "attachment identify the forwarder at the other end. We use the term "attachment
skipping to change at page 14, line 42 skipping to change at page 14, line 42
The SAII, TAII, and AGI are simply carried as octet strings. The The SAII, TAII, and AGI are simply carried as octet strings. The
length byte specifies the size of the Value field. The null string length byte specifies the size of the Value field. The null string
can be sent by setting the length byte to 0. If a particular can be sent by setting the length byte to 0. If a particular
application does not need all three of these sub-elements, it MUST application does not need all three of these sub-elements, it MUST
send all the sub-elements but set the length to 0 for the unused send all the sub-elements but set the length to 0 for the unused
sub-elements. sub-elements.
The PW information length field contains the length of the SAII, The PW information length field contains the length of the SAII,
TAII, and AGI, combined in octets. If this value is 0, then it TAII, and AGI, combined in octets. If this value is 0, then it
references all PWs using the specific grouping ID (specified in the references all PWs using the specific grouping ID (specified in the
PW grouping ID TLV). In this case, there are no other FEC element PW Group ID TLV). In this case, there are no other FEC element
fields (AGI, SAII, etc.) present, nor any interface parameters TLVs. fields (AGI, SAII, etc.) present, nor any interface parameters TLVs.
Note that the interpretation of a particular field as AGI, SAII, or Note that the interpretation of a particular field as AGI, SAII, or
TAII depends on the order of its occurrence. The type field TAII depends on the order of its occurrence. The type field
identifies the type of the AGI, SAII, or TAII. When comparing two identifies the type of the AGI, SAII, or TAII. When comparing two
occurrences of an AGI (or SAII or TAII), the two occurrences are occurrences of an AGI (or SAII or TAII), the two occurrences are
considered identical if the type, length, and value fields of one are considered identical if the type, length, and value fields of one are
identical, respectively, to those of the other. identical, respectively, to those of the other.
6.2.2.1. Interface Parameters TLV 6.2.2.1. Interface Parameters TLV
skipping to change at page 15, line 27 skipping to change at page 15, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value | | Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value | | Variable Length Value |
| " | | " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A more detailed description of this field can be found in the section A more detailed description of this field can be found in the section
"Interface Parameters Sub-TLV", below. "Interface Parameters Sub-TLV", below.
6.2.2.2. PW Grouping ID TLV 6.2.2.2. PW Group ID TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|PW Grouping ID TLV (0x096C)| Length | |0|0| PW Group ID TLV (0x096C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PW Grouping ID is an arbitrary 32-bit value that represents an The PW Group ID is an arbitrary 32-bit value that represents an
arbitrary group of PWs. It is used to create group PWs; for example, arbitrary group of PWs. It is used to create group PWs; for example,
a PW Grouping ID can be used as a port index and assigned to all PWs a PW Grouping ID can be used as a port index and assigned to all PWs
that lead to that port. Use of the PW Grouping ID enables one to that lead to that port. Use of the PW Group ID enables a PE to send
send "wild card" label withdrawals, or "wild card" status "wild card" label withdrawals, or "wild card" status notification
notification messages, to remote PEs upon physical port failure. messages, to remote PEs upon physical port failure.
Note Well: The PW Grouping ID is different from and has no relation Note Well: The PW Group ID is different from and has no relation to,
to, the Attachment Group Identifier. the Attachment Group Identifier.
The PW Grouping ID TLV is not part of the FEC and will not be The PW Group ID TLV is not part of the FEC and will not be advertised
advertised except in the PW FEC advertisement. The advertising PE except in the PW FEC advertisement. The advertising PE MAY use the
MAY use the wild card withdraw semantics, but the remote PEs MUST wild card withdraw semantics, but the remote PEs MUST implement
implement support for wild card messages. This TLV MUST only be used support for wild card messages. This TLV MUST only be used when
when sending the Generalized PW ID FEC. sending the Generalized PW ID FEC.
To issue a wild card command (status or withdraw): To issue a wild card command (status or withdraw):
- Set the PW Info Length to 0 in the Generalized PWid FEC Element. - Set the PW Info Length to 0 in the Generalized PWid FEC Element.
- Send only the PW Grouping ID TLV with the FEC (no AGI/SAII/TAII - Send only the PW Group ID TLV with the FEC (no AGI/SAII/TAII is
is sent). sent).
6.2.3. Signaling Procedures 6.2.3. Signaling Procedures
In order for PE1 to begin signaling PE2, PE1 must know the address of In order for PE1 to begin signaling PE2, PE1 must know the address of
the remote PE2, and a TAI. This information may have been configured the remote PE2, and a TAI. This information may have been configured
at PE1, or it may have been learned dynamically via some at PE1, or it may have been learned dynamically via some
autodiscovery procedure. autodiscovery procedure.
The egress PE (PE1), which has knowledge of the ingress PE, initiates The egress PE (PE1), which has knowledge of the ingress PE, initiates
the setup by sending a Label Mapping Message to the ingress PE (PE2). the setup by sending a Label Mapping Message to the ingress PE (PE2).
skipping to change at page 18, line 25 skipping to change at page 18, line 25
the Status Code field in octets (equal to 4). the Status Code field in octets (equal to 4).
Each bit in the status code field can be set individually to indicate Each bit in the status code field can be set individually to indicate
more than a single failure at once. Each fault can be cleared by more than a single failure at once. Each fault can be cleared by
sending an appropriate Notification message in which the respective sending an appropriate Notification message in which the respective
bit is cleared. The presence of the lowest bit (PW Not Forwarding) bit is cleared. The presence of the lowest bit (PW Not Forwarding)
acts only as a generic failure indication when there is a link-down acts only as a generic failure indication when there is a link-down
event for which none of the other bits apply. event for which none of the other bits apply.
The Status TLV is transported to the remote PW peer via the LDP The Status TLV is transported to the remote PW peer via the LDP
Notification message. The general format of the Notification Message Notification message as described in [RFC5036]. The format of the
is: Notification Message for carrying the PW Status is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length | |0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) | | Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Status TLV | | PW Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC TLV or Generalized ID FEC TLV | | PWId FEC TLV or Generalized ID FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Grouping ID TLV (Optional) | | PW Group ID TLV (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is set to 0x00000028, "PW status", to The Status TLV status code is set to 0x00000028, "PW status", to
indicate that PW status follows. Since this notification does not indicate that PW status follows. Since this notification does not
refer to any particular message, the Message Id and Message Type refer to any particular message, the Message Id field is set to 0.
fields are set to 0.
The PW FEC TLV SHOULD NOT include the interface parameter sub-TLVs, The PW FEC TLV SHOULD NOT include the interface parameter sub-TLVs,
as they are ignored in the context of this message. However the PW as they are ignored in the context of this message. However the PW
FEC TLV MUST include the C bit, where aplicable, as it is part of the FEC TLV MUST include the C-bit, where aplicable, as it is part of the
FEC. When a PE's attachment circuit encounters an error, use of the FEC. When a PE's attachment circuit encounters an error, use of the
PW Notification Message allows the PE to send a single "wild card" PW Notification Message allows the PE to send a single "wild card"
status message, using a PW FEC TLV with only the group ID set, to status message, using a PW FEC TLV with only the group ID set, to
denote this change in status for all affected PW connections. This denote this change in status for all affected PW connections. This
status message contains either the PW FEC TLV with only the group ID status message contains either the PW FEC TLV with only the group ID
set, or else it contains the Generalized FEC TLV with only the PW set, or else it contains the Generalized FEC TLV with only the PW
Grouping ID TLV. Group ID TLV.
As mentioned above, the Group ID field of the PWid FEC element, or As mentioned above, the Group ID field of the PWid FEC element, or
the PW Grouping ID TLV used with the Generalized PWid FEC element, the PW Grouping ID TLV used with the Generalized PWid FEC element,
can be used to send a status notification for all arbitrary sets of can be used to send a status notification for all arbitrary sets of
PWs. This procedure is OPTIONAL, and if it is implemented, the LDP PWs. This procedure is OPTIONAL, and if it is implemented, the LDP
Notification message should be as follows: If the PWid FEC element is Notification message should be as follows: If the PWid FEC element is
used, the PW information length field is set to 0, the PW ID field is used, the PW information length field is set to 0, the PW ID field is
not present, and the interface parameter sub-TLVs are not present. not present, and the interface parameter sub-TLVs are not present.
If the Generalized FEC element is used, the AGI, SAII, and TAII are If the Generalized FEC element is used, the AGI, SAII, and TAII are
not present, the PW information length field is set to 0, the PW not present, the PW information length field is set to 0, the PW
Grouping ID TLV is included, and the Interface Parameters TLV is Group ID TLV is included, and the Interface Parameters TLV is
omitted. For the purpose of this document, this is called the "wild omitted. For the purpose of this document, this is called the "wild
card PW status notification procedure", and all PEs implementing this card PW status notification procedure", and all PEs implementing this
design are REQUIRED to accept such a notification message but are not design are REQUIRED to accept such a notification message but are not
required to send it. required to send it.
6.3.3. Pseudowire Status Negotiation Procedures 6.3.3. Pseudowire Status Negotiation Procedures
When a PW is first set up, the PEs MUST attempt to negotiate the When a PW is first set up, the PEs MUST attempt to negotiate the
usage of the PW status TLV. This is accomplished as follows: A PE usage of the PW status TLV. This is accomplished as follows: A PE
that supports the PW Status TLV MUST include it in the initial Label that supports the PW Status TLV MUST include it in the initial Label
skipping to change at page 22, line 16 skipping to change at page 22, line 16
As mentioned above, the Group ID field of the PWid FEC element, or As mentioned above, the Group ID field of the PWid FEC element, or
the PW Grouping ID TLV used with the Generalized PWid FEC element, the PW Grouping ID TLV used with the Generalized PWid FEC element,
can be used to withdraw all PW labels associated with a particular PW can be used to withdraw all PW labels associated with a particular PW
group. This procedure is OPTIONAL, and if it is implemented, the LDP group. This procedure is OPTIONAL, and if it is implemented, the LDP
Label Withdraw message should be as follows: If the PWid FEC element Label Withdraw message should be as follows: If the PWid FEC element
is used, the PW information length field is set to 0, the PW ID field is used, the PW information length field is set to 0, the PW ID field
is not present, the interface parameter sub-TLVs are not present, and is not present, the interface parameter sub-TLVs are not present, and
the Label TLV is not present. If the Generalized FEC element is the Label TLV is not present. If the Generalized FEC element is
used, the AGI, SAII, and TAII are not present, the PW information used, the AGI, SAII, and TAII are not present, the PW information
length field is set to 0, the PW Grouping ID TLV is included, the length field is set to 0, the PW Group ID TLV is included, the
Interface Parameters TLV is not present, and the Label TLV is not Interface Parameters TLV is not present, and the Label TLV is not
present. For the purpose of this document, this is called the "wild present. For the purpose of this document, this is called the "wild
card withdraw procedure", and all PEs implementing this design are card withdraw procedure", and all PEs implementing this design are
REQUIRED to accept such withdrawn message but are not required to REQUIRED to accept such withdrawn message but are not required to
send it. Note that the PW Grouping ID TLV only applies to PWs using send it. Note that the PW Group ID TLV only applies to PWs using the
the Generalized ID FEC element, while the Group ID only applies to Generalized ID FEC element, while the Group ID only applies to PWid
PWid FEC element. FEC element.
The interface parameter sub-TLVs, or TLV, MUST NOT be present in any The interface parameter sub-TLVs, or TLV, MUST NOT be present in any
LDP PW Label Withdraw or Label Release message. A wild card Label LDP PW Label Withdraw or Label Release message. A wild card Label
Release message MUST include only the group ID, or Grouping ID TLV. Release message MUST include only the group ID, or Grouping ID TLV.
A Label Release message initiated by a PE router must always include A Label Release message initiated by a PE router must always include
the PW ID. the PW ID.
7. Control Word 7. Control Word
7.1. PW Types for which the Control Word is REQUIRED 7.1. PW Types for which the Control Word is REQUIRED
The Label Mapping messages that are sent in order to set up these PWs The Label Mapping messages that are sent in order to set up these PWs
MUST have c=1. When a Label Mapping message for a PW of one of these MUST have C=1. When a Label Mapping message for a PW of one of these
types is received and c=0, a Label Release message MUST be sent, with types is received and C=0, a Label Release message MUST be sent, with
an "Illegal C-bit" status code. In this case, the PW will not be an "Illegal C-bit" status code. In this case, the PW will not be
enabled. enabled
7.2. PW Types for which the Control Word is NOT mandatory 7.2. PW Types for which the Control Word is NOT mandatory
If a system is capable of sending and receiving the control word on If a system is capable of sending and receiving the control word on
PW types for which the control word is not mandatory, then each such PW types for which the control word is not mandatory, then each such
PW endpoint MUST be configurable with a parameter that specifies PW endpoint MUST be configurable with a parameter that specifies
whether the use of the control word is PREFERRED or NOT PREFERRED. whether the use of the control word is PREFERRED or NOT PREFERRED.
For each PW, there MUST be a default value of this parameter. This For each PW, there MUST be a default value of this parameter. This
specification does NOT state what the default value should be. specification does NOT state what the default value should be.
If a system is NOT capable of sending and receiving the control word If a system is NOT capable of sending and receiving the control word
on PW types for which the control word is not mandatory, then it on PW types for which the control word is not mandatory, then it
behaves exactly as if it were configured for the use of the control behaves exactly as if it were configured for the use of the control
word to be NOT PREFERRED. word to be NOT PREFERRED.
If a Label Mapping message for the PW has already been received but If a Label Mapping message for the PW has already been received but
no Label Mapping message for the PW has yet been sent, then the no Label Mapping message for the PW has yet been sent, then the
procedure is as follows: procedure is as follows:
-i. If the received Label Mapping message has c=0, send a Label -i. If the received Label Mapping message has C=0, send a Label
Mapping message with c=0; the control word is not used. Mapping message with C=0; the control word is not used.
-ii. If the received Label Mapping message has c=1, and the PW is -ii. If the received Label Mapping message has C=1, and the PW is
locally configured such that the use of the control word is locally configured such that the use of the control word is
preferred, then send a Label Mapping message with c=1; the preferred, then send a Label Mapping message with C=1; the
control word is used. control word is used.
-iii. If the received Label Mapping message has c=1, and the PW is -iii. If the received Label Mapping message has C=1, and the PW is
locally configured such that the use of the control word is locally configured such that the use of the control word is
not preferred or the control word is not supported, then act not preferred or the control word is not supported, then act
as if no Label Mapping message for the PW had been received as if no Label Mapping message for the PW had been received
(That is: proceed to the next paragraph). (That is: proceed to the next paragraph).
If a Label Mapping message for the PW has not already been received If a Label Mapping message for the PW has not already been received
(or if the received Label Mapping message had c=1 and either local (or if the received Label Mapping message had C=1 and either local
configuration says that the use of the control word is not preferred configuration says that the use of the control word is not preferred
or the control word is not supported), then send a Label Mapping or the control word is not supported), then send a Label Mapping
message in which the c bit is set to correspond to the locally message in which the C-bit is set to correspond to the locally
configured preference for use of the control word. (That is, set c=1 configured preference for use of the control word. (That is, set C=1
if locally configured to prefer the control word, and set c=0 if if locally configured to prefer the control word, and set C=0 if
locally configured to prefer not to use the control word or if the locally configured to prefer not to use the control word or if the
control word is not supported). control word is not supported).
The next action depends on what control message is next received for The next action depends on what control message is next received for
that PW. The possibilities are as follows: that PW. The possibilities are as follows:
-i. A Label Mapping message with the same c bit value as -i. A Label Mapping message with the same C-bit value as
specified in the Label Mapping message that was sent. PW specified in the Label Mapping message that was sent. PW
setup is now complete, and the control word is used if c=1 setup is now complete, and the control word is used if C=1
but is not used if c=0. but is not used if C=0.
-ii. A Label Mapping message with c=1, but the Label Mapping -ii. A Label Mapping message with C=1, but the Label Mapping
message that was sent has c=0. In this case, ignore the message that was sent has C=0. In this case, ignore the
received Label Mapping message and continue to wait for the received Label Mapping message and continue to wait for the
next control message for the PW. next control message for the PW.
-iii. A Label Mapping message with c=0, but the Label Mapping -iii. A Label Mapping message with C=0, but the Label Mapping
message that was sent has c=1. In this case, send a Label message that was sent has C=1. In this case, send a Label
Withdraw message with a "Wrong C-bit" status code, followed Withdraw message with a "Wrong C-bit" status code, followed
by a Label Mapping message that has c=0. PW setup is now by a Label Mapping message that has C=0. PW setup is now
complete, and the control word is not used. complete, and the control word is not used.
-iv. A Label Withdraw message with the "Wrong c-bit" status code. -iv. A Label Withdraw message with the "Wrong C-bit" status code.
Treat as a normal Label Withdraw, but do not respond. Treat as a normal Label Withdraw, but do not respond.
Continue to wait for the next control message for the PW. Continue to wait for the next control message for the PW.
If at any time after a Label Mapping message has been received a If at any time after a Label Mapping message has been received a
corresponding Label Withdraw or Release is received, the action taken corresponding Label Withdraw or Release is received, the action taken
is the same as for any Label Withdraw or Release that might be is the same as for any Label Withdraw or Release that might be
received at any time. received at any time.
If both endpoints prefer the use of the control word, this procedure If both endpoints prefer the use of the control word, this procedure
will cause it to be used. If either endpoint prefers not to use the will cause it to be used. If either endpoint prefers not to use the
control word or does not support the control word, this procedure control word or does not support the control word, this procedure
will cause it not to be used. If one endpoint prefers to use the will cause it not to be used. If one endpoint prefers to use the
control word but the other does not, the one that prefers not to use control word but the other does not, the one that prefers not to use
it has no extra protocol to execute; it just waits for a Label it has no extra protocol to execute; it just waits for a Label
Mapping message that has c=0. Mapping message that has C=0.
7.3. Control-Word Renegotiation by Label Request Message 7.3. Control-Word Renegotiation by Label Request Message
It is possible that after the PW C-bit negotation procedure described It is possible that after the PW C-bit negotation procedure described
above is completed, the local PE is re-provisioned with a different above is completed, the local PE is re-provisioned with a different
control word preference. Therefore once the Control-Word negotation control word preference. Therefore once the Control-Word negotation
procedures are completed, the procedure can be restarted as follows: procedures are completed, the procedure can be restarted as follows:
-i. If local PE has previously sent a Label Mapping message, it -i. If local PE has previously sent a Label Mapping message, it
MUST send a Label Withdraw message to remote PE and wait MUST send a Label Withdraw message to remote PE and wait
until it has received a Label Release message from the until it has received a Label Release message from the
remote PE. remote PE.
-ii. the local PE MUST send a label release message to the remote -ii. the local PE MUST send a label release message to the remote
PE for the specific label associated with the FEC that was PE for the specific label associated with the FEC that was
advertized for this specific PW. Note: the above-mentioned advertized for this specific PW. Note: the above-mentioned
steps of the Label Release message and Label Withdraw steps of the Label Release message and Label Withdraw
message are not required to be excuted in any specific message are not required to be excuted in any specific
sequence. sequence.
-iii. The local PE MUST send a Label Request message to the peer -iii. The local PE MUST send a Label Request message to the peer
PE, and then MUST wait until it receives a Label Mapping PE, and then MUST wait until it receives a Label Mapping
message containing the remote PE current configured message containing the remote PE's currently configured
preference for use of control word. preference for use of the control word.
Once the remote PE has successfully processed the Label Withdraw Once the remote PE has successfully processed the Label Withdraw
message and Label Release messages, it will reset the C-Bit message and Label Release messages, it will reset the C-bit
negotation state machine and its use of control word with the locally negotation state machine and its use of the control word with the
configured preference. locally configured preference.
From this point on the local and remote PEs will follow the C-bit From this point on the local and remote PEs will follow the C-bit
negotaiation procedures defined in the previous section. negotaiation procedures defined in the previous section.
The above C-bit renegotation process SHOULD NOT be interupted until The above C-bit renegotation process SHOULD NOT be interupted until
it is completed, or unpredictable results might occur. it is completed, or unpredictable results might occur.
7.4. Sequencing Considerations 7.4. Sequencing Considerations
In the case where the router considers the sequence number field in In the case where the router considers the sequence number field in
skipping to change at page 26, line 7 skipping to change at page 26, line 7
In situations where the imposition router wants to restart forwarding In situations where the imposition router wants to restart forwarding
of packets with sequence number 1, the router shall 1) send to the of packets with sequence number 1, the router shall 1) send to the
disposition router a Label Release Message, and 2) send to the disposition router a Label Release Message, and 2) send to the
disposition router a Label Request message. When sequencing is disposition router a Label Request message. When sequencing is
supported, advertisement of a PW label in response to a Label Request supported, advertisement of a PW label in response to a Label Request
message MUST also consider the issues discussed in the section on message MUST also consider the issues discussed in the section on
Label Advertisements. Label Advertisements.
8. IANA Considerations 8. IANA Considerations
In general IANA needs to update any references in the registries The authors request that IANA remove this section before publication
referring to RFC4447 to this document. and that IANA update any references to [RFC4447] in their registries
to refer to this document.
8.1. LDP TLV TYPE
This document uses several new LDP TLV types; IANA already maintains
a registry of name "TLV TYPE NAME SPACE" defined by RFC 5036. Any
references to RFC4447 need to be updated to reference this document.
8.2. LDP Status Codes
This document uses several new LDP status codes; IANA already
maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC
5036. Any references to RFC4447 need to be updated to reference this
document.
8.3. FEC Type Name Space
This document uses two new FEC element types, 0x80 and 0x81, from the
registry "FEC Type Name Space" for the Label Distribution Protocol
(LDP RFC 5036). Any references to RFC4447 need to be updated to
reference this document.
9. Security Considerations 9. Security Considerations
This document specifies the LDP extensions that are needed for This document specifies the LDP extensions that are needed for
setting up and maintaining pseudowires. The purpose of setting up setting up and maintaining pseudowires. The purpose of setting up
pseudowires is to enable Layer 2 frames to be encapsulated in MPLS pseudowires is to enable Layer 2 frames to be encapsulated in MPLS
and transmitted from one end of a pseudowire to the other. Therefore and transmitted from one end of a pseudowire to the other. Therefore
we treat the security considerations for both the data plane and the we treat the security considerations for both the data plane and the
control plane. control plane.
skipping to change at page 28, line 8 skipping to change at page 27, line 25
of the packet's integrity.) A third problem is the possibility that of the packet's integrity.) A third problem is the possibility that
the PDU's contents will be seen while the PDU is in transit through the PDU's contents will be seen while the PDU is in transit through
the PSN (i.e., the specification encapsulations do not ensure the PSN (i.e., the specification encapsulations do not ensure
privacy.) How significant these issues are in practice depends on privacy.) How significant these issues are in practice depends on
the security requirements of the applications whose traffic is being the security requirements of the applications whose traffic is being
sent through the tunnel, and how secure the PSN itself is. sent through the tunnel, and how secure the PSN itself is.
9.2. Control-Plane Security 9.2. Control-Plane Security
General security considerations with regard to the use of LDP are General security considerations with regard to the use of LDP are
specified in section 5 of RFC 5036. Those considerations also apply specified in section 5 of [RFC5036]. Those considerations also apply
to the case where LDP is used to set up pseudowires. to the case where LDP is used to set up pseudowires.
A pseudowire connects two attachment circuits. It is important to A pseudowire connects two attachment circuits. It is important to
make sure that LDP connections are not arbitrarily accepted from make sure that LDP connections are not arbitrarily accepted from
anywhere, or else a local attachment circuit might get connected to anywhere, or else a local attachment circuit might get connected to
an arbitrary remote attachment circuit. Therefore, an incoming LDP an arbitrary remote attachment circuit. Therefore, an incoming LDP
session request MUST NOT be accepted unless its IP source address is session request MUST NOT be accepted unless its IP source address is
known to be the source of an "eligible" LDP peer. The set of known to be the source of an "eligible" LDP peer. The set of
eligible peers could be pre-configured (either as a list of IP eligible peers could be pre-configured (either as a list of IP
addresses, or as a list of address/mask combinations), or it could be addresses, or as a list of address/mask combinations), or it could be
skipping to change at page 28, line 32 skipping to change at page 27, line 49
trusted.) trusted.)
Even if an LDP connection request appears to come from an eligible Even if an LDP connection request appears to come from an eligible
peer, its source address may have been spoofed. Therefore, some peer, its source address may have been spoofed. Therefore, some
means of preventing source address spoofing must be in place. For means of preventing source address spoofing must be in place. For
example, if all the eligible peers are in the same network, source example, if all the eligible peers are in the same network, source
address filtering at the border routers of that network could address filtering at the border routers of that network could
eliminate the possibility of source address spoofing. eliminate the possibility of source address spoofing.
The LDP MD5 authentication key option, as described in section 2.9 of The LDP MD5 authentication key option, as described in section 2.9 of
RFC 5036, MUST be implemented, and for a greater degree of security, [RFC5036], MUST be implemented, and for a greater degree of security,
it must be used. This provides integrity and authentication for the it must be used. This provides integrity and authentication for the
LDP messages and eliminates the possibility of source address LDP messages and eliminates the possibility of source address
spoofing. Use of the MD5 option does not provide privacy, but spoofing. Use of the MD5 option does not provide privacy, but
privacy of the LDP control messages is not usually considered privacy of the LDP control messages is not usually considered
important. As the MD5 option relies on the configuration of pre- important. As the MD5 option relies on the configuration of pre-
shared keys, it does not provide much protection against replay shared keys, it does not provide much protection against replay
attacks. In addition, its reliance on pre-shared keys may make it attacks. In addition, its reliance on pre-shared keys may make it
very difficult to deploy when the set of eligible neighbors is very difficult to deploy when the set of eligible neighbors is
determined by an auto-configuration protocol. determined by an auto-configuration protocol.
skipping to change at page 29, line 19 skipping to change at page 28, line 37
Internet Standard must meet. This section documents how this Internet Standard must meet. This section documents how this
document meets those requirements. document meets those requirements.
The pseudowire technology was first deployed in 2001 and has been The pseudowire technology was first deployed in 2001 and has been
widely deployed by many carriers. [RFC7079] documents the results of widely deployed by many carriers. [RFC7079] documents the results of
a survey of PW implementations, with specific emphasis on Control a survey of PW implementations, with specific emphasis on Control
Word usage. [EANTC] documents a public multi-vendor interoperability Word usage. [EANTC] documents a public multi-vendor interoperability
test of MPLS and Carrier Ethernet equipment, which included testing test of MPLS and Carrier Ethernet equipment, which included testing
of Ethernet, ATM and TDM pseudowires. of Ethernet, ATM and TDM pseudowires.
The errata against [RFC4447] are all editorial in nature and have The errata against [RFC4447] are generally editorial in nature and
been addressed in this document. have been addressed in this document.
All features in this specification have been implemented by multiple All features in this specification have been implemented by multiple
vendors. vendors.
There is no IPR filed against this document or its predecessor. No IPR disloures have been made to the IETF related to this document,
to RFC4447 or RFC6723, or to the Internet-Drafts that resulted in
RFC4447 and RFC6723.
11. Acknowledgments 11. Acknowledgments
The authors wish to acknowledge the contributions of Vach Kompella, The authors wish to acknowledge the contributions of Vach Kompella,
Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds. Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds. The authors wish
to also acknowledge the contribution of the authors of rfc6723,
Lizhong Jin, Raymond Key, Simon Delord, Tom Nadeau, Sami Boutros,
whose work has been incorporated in this revised document.
12. Normative References 12. Normative References
[RFC2119] Bradner S., "Key words for use in RFCs to Indicate [RFC2119] Bradner S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
[RFC5036] "LDP Specification." L. Andersson, P. Ed. [RFC5036] "LDP Specification." Andersson, L. Ed.,
Minei, I. Ed. B. Thomas. January 2001. RFC5036, October 2007 Minei, I. Ed., Thomas, B. Ed. January 2001. RFC5036,
October 2007
[RFC3032] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, [RFC3032] "MPLS Label Stack Encoding", Rosen E., Rekhter Y.,
D. Tappan, G. Fedorkow, D. Farinacci, T. Li, A. Conta. Tappan D., Fedorkow G., Farinacci D., Li T., Conta A..
RFC3032 RFC3032
[RFC4446] "IANA Allocations for pseudo Wire Edge to Edge Emulation [RFC4446] "IANA Allocations for pseudo Wire Edge to Edge Emulation
(PWE3)" L. Martini RFC4446, April 2006 (PWE3)" Martini L. RFC4446, April 2006
[RFC7358] "Label Advertisement Discipline for LDP Forwarding [RFC7358] "Label Advertisement Discipline for LDP Forwarding
Equivalence Classes (FECs)", K. Raza, S. Boutros, L. Martini, Equivalence Classes (FECs)", Raza K., Boutros S., Martini L.,
RFC7358, October 2014 RFC7358, October 2014
13. Informative References 13. Informative References
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985. [RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985.
[RFC4842] "Synchronous Optical Network/Synchronous Digital Hierarchy [RFC4842] "Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Circuit Emulation over Packet (CEP)", A. Malis, (SONET/SDH) Circuit Emulation over Packet (CEP)", A. Malis,
P. Pate, R. Cohen, Ed., D. Zelig, RFC4842, April 2007 P. Pate, R. Cohen, Ed., D. Zelig, RFC4842, April 2007
[RFC4553] "Structure-Agnostic Time Division Multiplexing (TDM) over [RFC4553] "Structure-Agnostic Time Division Multiplexing (TDM) over
Packet (SAToP)", Vainshtein A. Ed. Stein, Ed. YJ. RFC4553, Packet (SAToP)", Vainshtein A. Ed., Stein, YJ. Ed. RFC4553,
June 2006 June 2006
[RFC4619] "Encapsulation Methods for Transport of Frame Relay over [RFC4619] "Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks", Martini L. Ed. Multiprotocol Label Switching (MPLS) Networks", Martini L. Ed.
C. Kawa Ed. A. Malis Ed. RFC4619, September 2006 C. Kawa Ed., A. Malis, Ed. RFC4619, September 2006
[RFC4717] "Encapsulation Methods for Transport of Asynchronous [RFC4717] "Encapsulation Methods for Transport of Asynchronous
Transfer Mode (ATM) over MPLS Networks", Martini L. Jayakumar J. Transfer Mode (ATM) over MPLS Networks", Martini L., Jayakumar
Bocci M. El-Aawar N. Brayley J. Koleyni G. RFC4717, J., Bocci M., El-Aawar N., Brayley J., Koleyni G. RFC4717,
December 2006 December 2006
[RFC4618] "Encapsulation Methods for Transport of PPP/High-Level [RFC4618] "Encapsulation Methods for Transport of PPP/High-Level
Data Link Control (HDLC) Frames over MPLS Networks", Martini L. Data Link Control (HDLC) Frames over MPLS Networks", Martini L.
Rosen E. Heron G. Malis A. RFC4618, September 2006 Rosen E., Heron G., Malis A. RFC4618, September 2006
[RFC4448] "Encapsulation Methods for Transport of Ethernet over [RFC4448] "Encapsulation Methods for Transport of Ethernet over
MPLS Networks", Martini L. Ed. Rosen E. El-Aawar N. Heron G. MPLS Networks", Martini L. Ed., Rosen E., El-Aawar N., Heron
RFC4448, April 2006. G. RFC4448, April 2006.
[RFC4447] "Pseudowire Setup and Maintenance Using the Label [RFC4447] "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", Martini L. Ed. Rosen E. Distribution Protocol (LDP)", Martini L. Ed., Rosen E.,
El-Aawar N. Smith T. Heron G. RFC4447, April 2006 El-Aawar N., Smith T., Heron G. RFC4447, April 2006
[RFC6410] "Reducing the Standards Track to Two Maturity Levels",
Housley R., Crocker D., Burger E. RFC6410, October 2011
[RFC6723] "Update of the Pseudowire Control-Word Negotiation
Mechanism", Jin L. Ed., Key R. Ed., Delord S., Nadeau T.,
Boutros S. RFC5723, September 2012
[RFC6410] "Reducing the Standads Track to Two Maturity Levels", [RFC6410] "Reducing the Standads Track to Two Maturity Levels",
Housley R. Crocker D. Burger E. RFC6410, October 2011 Housley R., Crocker D., Burger E. RFC6410, October 2011
[RFC7079] "The Pseudowire (PW) and Virtual Circuit Connectivity [RFC7079] "The Pseudowire (PW) and Virtual Circuit Connectivity
Verification (VCCV) Implementation Survey Results", Del Regno N. Verification (VCCV) Implementation Survey Results", Del Regno
Malis A. RFC7079, November 2013 N., Malis A. RFC7079, November 2013
[ANSI] American National Standards Institute, "Synchronous Optical [ANSI] American National Standards Institute, "Synchronous Optical
Network Formats", ANSI T1.105-1995. Network Formats", ANSI T1.105-1995.
[ITUG] ITU Recommendation G.707, "Network Node Interface For The [ITUG] ITU Recommendation G.707, "Network Node Interface For The
Synchronous Digital Hierarchy", 1996. Synchronous Digital Hierarchy", 1996.
[EANTC] The European Advanced Networking Test Center "MPLS and [EANTC] The European Advanced Networking Test Center "MPLS and
Carrier Ethernet: Service - Connect - Transport. Public Multi-Vendor Carrier Ethernet: Service - Connect - Transport. Public
Interoperability Test", February 2009. Multi-Vendor Interoperability Test", February 2009.
14. Author Information 14. Author Information
Luca Martini Luca Martini
Cisco Systems, Inc. Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400 1899 Wynkoop Street
Englewood, CO, 80112 Suite 600
Denver, CO, 80202
e-mail: lmartini@cisco.com e-mail: lmartini@cisco.com
Giles Heron Giles Heron
Cisco Systems Cisco Systems
10 New Square 10 New Square
Bedfont Lakes Bedfont Lakes
Feltham Feltham
Middlesex Middlesex
TW14 8HA TW14 8HA
UK UK
skipping to change at page 34, line 7 skipping to change at page 34, line 7
e-mail: dcooper@gblx.net e-mail: dcooper@gblx.net
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: kireeti@juniper.net e-mail: kireeti@juniper.net
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 34, line 32 skipping to change at page 34, line 32
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Expiration Date: August 2016 Expiration Date: January 2017
 End of changes. 67 change blocks. 
135 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/