| < 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/ | ||||