idnits 2.17.1 draft-ietf-pwe3-control-protocol-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1202. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1215. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The PW FEC TLV SHOULD not include the interface parameter sub-TLVs as they are ignored in the context of this message. When a PE's attachment circuit encounters an error, use of the 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 denote this change in status for all affected PW connections. This 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 Grouping ID TLV. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When a MPLS PSN is used to provide pseudowire service, there is a perception that security MUST be at least equal to the currently deployed layer2 native protocol networks that the MPLS/PW network combination is emulating. This means that the MPLS enabled network SHOULD be isolated from outside packet insertion in such a way that it SHOULD not be possible to directly insert an MPLS packet into the network. To prevent unwanted packet insertion, it is also important to prevent unauthorized physical access to the PSN as well as unauthorized administrative access to individual network elements. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6889 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3036' is mentioned on line 139, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'SaTOP' is mentioned on line 356, but not defined -- Looks like a reference, but probably isn't: '1' on line 1028 -- Looks like a reference, but probably isn't: '32768' on line 1028 == Unused Reference: 'PPPHDLC' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: 'SDH' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1281, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-08 == Outdated reference: A later version (-14) exists of draft-ietf-pwe3-sonet-11 == Outdated reference: A later version (-05) exists of draft-ietf-pwe3-satop-01 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-frame-relay-02 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-atm-encap-05 -- No information found for draft-ietf-pwe3-hdlc-ppp-encap - is the name correct? == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-06 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini (ED) 3 Internet Draft Eric C. Rosen 4 Expiration Date: December 2005 Cisco Systems, Inc. 6 Nasser El-Aawar Toby Smith 7 Level 3 Communications, LLC. Laurel Networks, Inc. 9 Giles Heron 10 Tellabs 11 June 2005 13 Pseudowire Setup and Maintenance using the Label Distribution Protocol 15 draft-ietf-pwe3-control-protocol-17.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 Layer 2 services (such as Frame Relay, Asyncronus Transfer Mode, 42 Ethernet) can be "emulated" over an MPLS backbone by encapsulating 43 the layer 2 Packet Data Units (PDU) and then transmitting them over 44 "pseudowires". It is also possible to use pseudowires to provide 45 low-rate Time Dividion Multiplexed and a Synchronous Optical 46 NETworking circuit emulation over a MPLS enabled network. This 47 document specifies a protocol for establishing and maintaining the 48 pseudowires, using extensions to Label Distribution Protocol (LDP). 49 Procedures for encapsulating layer 2 PDUs are specified in a set of 50 companion documents. 52 Table of Contents 54 1 Specification of Requirements ........................ 4 55 2 Introduction ......................................... 4 56 3 The Pseudowire Label ................................. 6 57 4 Details Specific to Particular Emulated Services ..... 8 58 4.1 IP Layer2 Transport .................................. 8 59 5 LDP .................................................. 8 60 5.1 LDP Extensions ....................................... 9 61 5.2 The PWid FEC Element ................................. 9 62 5.3 The Generalized PWid FEC Element ..................... 11 63 5.3.1 Attachment Identifiers ............................... 12 64 5.3.2 Encoding the Generalized ID FEC Element .............. 13 65 5.3.2.1 Interface Parameters TLV ............................. 15 66 5.3.2.2 PW Grouping TLV ...................................... 15 67 5.3.3 Signaling Procedures ................................. 16 68 5.4 Signaling of Pseudo Wire Status ...................... 17 69 5.4.1 Use of Label Mappings Messages. ...................... 17 70 5.4.2 Signaling PW status. ................................. 18 71 5.4.3 Pseudowire Status Negotiation Procedures ............. 19 72 5.5 Interface Parameters sub-TLV ......................... 21 73 6 Control Word ......................................... 22 74 6.1 PW types for which the control word is REQUIRED ...... 22 75 6.2 PW types for which the control word is NOT mandatory . 22 76 6.3 LDP label Withdrawal procedures ...................... 23 77 6.4 Sequencing Considerations ............................ 24 78 6.4.1 Label Advertisements ................................. 24 79 6.4.2 Label Release ........................................ 25 80 7 IANA Considerations .................................. 25 81 7.1 LDP TLV TYPE ......................................... 25 82 7.2 LDP Status Codes ..................................... 25 83 7.3 FEC Type Name Space .................................. 26 84 8 Security Considerations .............................. 26 85 8.1 Data-plane Security .................................. 26 86 8.2 Control Protocol Security ............................ 27 87 9 Intellectual Property Statement ...................... 28 88 10 Full Copyright Statement ............................. 29 89 11 Acknowledgments ...................................... 29 90 12 Normative References ................................. 29 91 13 Informative References ............................... 29 92 14 Author Information ................................... 30 93 15 Additional Contributing Authors ...................... 31 94 Ap A C-bit Handling Procedures Diagram .................... 34 96 1. Specification of Requirements 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119. 102 2. Introduction 104 In [FRAME], [ATM], and [ETH] it is explained how to encapsulate a 105 layer 2 Protocol Data Unit (PDU) for transmission over an MPLS 106 enabled network. Those documents specify that a "pseudowire header", 107 consisting of a demultiplexor field, will be prepended to the 108 encapsulated PDU. The pseudowire demultiplexor field is put on before 109 transmitting a packet on a pseudowire. When the packet arrives at the 110 remote endpoint of the pseudowire, the demultiplexor is what enables 111 the receiver to identify the particular pseudowire on which the 112 packet has arrived. To actually transmit the packet from one 113 pseudowire endpoint to another, the packet may need to travel through 114 a "Public switched Network (PSN) tunnel"; this will require an 115 additional header to be prepended to the packet. 117 Accompanying documents [CEP, SAToP] specify methods for transporting 118 time division multiplexed (TDM) digital signals (TDM circuit 119 emulation) over a packet-oriented MPLS enabled network. The 120 transmission system for circuit-oriented TDM signals is the 121 Synchronous Optical Network (SONET)[SDH]/Synchronous Digital 122 Hierarchy (SDH) [ITUG]. To support TDM traffic, which includes voice, 123 data, and private leased line service, the pseudowires must emulate 124 the circuit characteristics of SONET/SDH payloads. The TDM signals 125 and payloads are encapsulated for transmission over pseudowires. To 126 this encapsulation is prepended a pseudowire demultiplexor and a PSN 127 tunnel header. 129 [SAToP] describe methods for transporting low-rate time division 130 multiplexed (TDM) digital signals (TDM circuit emulation) over PSNs, 131 while [CEP] similarly describes transport of high-rate TDM 132 (SONET/SDH). To support TDM traffic the pseudowires must emulate the 133 circuit characteristics of the original T1, E1, T3, E3, SONET or SDH 134 signals. [SAToP] does this by encapsulating an arbitrary but constant 135 amount of the TDM data in each packet, while the other methods 136 encapsulate TDM structures. 138 In this document, we specify the use of the MPLS Label Distribution 139 Protocol, LDP [RFC3036], as a protocol for setting up and maintaining 140 the pseudowires. In particular, we define new TLVs, FEC elements, 141 parameters and codes for LDP, which enable LDP to identify 142 pseudowires and to signal attributes of pseudowires. We specify how a 143 pseudowire endpoint uses these TLVs in LDP to bind a demultiplexor 144 field value to a pseudowire, and how it informs the remote endpoint 145 of the binding. We also specify procedures for reporting pseudowire 146 status changes, passing additional information about the pseudowire 147 as needed, and for releasing the bindings. 149 In the protocol specified herein, the pseudowire demultiplexor field 150 is an MPLS label. Thus the packets which are transmitted from one end 151 of the pseudowire to the other are MPLS packets which must be 152 transmitted through a MPLS tunnel. However if the pseudowire 153 endpoints are immediately adjacent, and penultimate hop popping 154 behaviour is in use, the MPLS tunnel may not be necessary. Any sort 155 of PSN tunnel can be used, as long as it is possible to transmit MPLS 156 packets through it. The PSN tunnel can itself be an MPLS LSP, or any 157 other sort of tunnel which can carry MPLS packets. Procedures for 158 setting up and maintaining the MPLS tunnels are outside the scope of 159 this document. 161 This document deals only with the setup and maintenance of point-to- 162 point pseudowires. Neither point to multipoint nor multipoint to 163 point pseudowires are discussed. 165 QoS related issues are not discussed in this document. The following 166 two figures describe the reference models which are derived from 167 [RFC3985] to support the PW emulated services. 169 |<-------------- Emulated Service ---------------->| 170 | | 171 | |<------- Pseudo Wire ------>| | 172 | | | | 173 |Attachment| |<-- PSN Tunnel -->| |Attachment| 174 | Circuit V V V V Circuit | 175 V (AC) +----+ +----+ (AC) V 176 +-----+ | | PE1|==================| PE2| | +-----+ 177 | |----------|............PW1.............|----------| | 178 | CE1 | | | | | | | | CE2 | 179 | |----------|............PW2.............|----------| | 180 +-----+ ^ | | |==================| | | ^ +-----+ 181 ^ | +----+ +----+ | | ^ 182 | | Provider Edge 1 Provider Edge 2 | | 183 | | | | 184 Customer | | Customer 185 Edge 1 | | Edge 2 186 | | 187 native service native service 189 Figure 1: PWE3 Reference Model 191 +-----------------+ +-----------------+ 192 |Emulated Service | |Emulated Service | 193 |(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) | 194 +-----------------+ +-----------------+ 195 | Payload | | Payload | 196 | Encapsulation |<====== Pseudo Wire ======>| Encapsulation | 197 +-----------------+ +-----------------+ 198 |PW Demultiplexer | |PW Demultiplexer | 199 | PSN Tunnel, |<======= PSN Tunnel ======>| PSN Tunnel, | 200 | PSN & Physical | | PSN & Physical | 201 | Layers | | Layers | 202 +-------+---------+ ___________ +---------+-------+ 203 | / | 204 +===============/ PSN ===============+ 205 / 206 _____________/ 208 Figure 2: PWE3 Protocol Stack Reference Model 210 For the purpose of this document, PE1 will be defined as the ingress 211 router, and PE2 as the egress router. A layer 2 PDU will be received 212 at PE1, encapsulated at PE1, transported, decapsulated at PE2, and 213 transmitted out of PE2. 215 3. The Pseudowire Label 217 Suppose it is desired to transport layer 2 PDUs from ingress LSR PE1 218 to egress LSR PE2, across an intervening MPLS enabled network. We 219 assume that there is a MPLS tunnel from PE1 to PE2. That is, we 220 assume that PE1 can cause a packet to be delivered to PE2 by 221 encapsulating the packet in a "MPLS tunnel header" and sending the 222 result to one of its adjacencies. The MPLS tunnel is an MPLS Label 223 Switched Path (LSP), hence putting on a MPLS tunnel encapsulation is 224 a matter of pushing on an MPLS label. 226 We presuppose that a large number of pseudowires can be carried 227 through a single MPLS tunnel. Thus it is never necessary to maintain 228 state in the network core for individual pseudowires. We do not 229 presuppose that the MPLS tunnels are point to point; although the 230 pseudowires are point to point, the MPLS tunnels may be multipoint to 231 point. We do not presuppose that PE2 will even be able to determine 232 the MPLS tunnel through which a received packet was transmitted. 233 (E.g., if the MPLS tunnel is an LSP, and penultimate hop popping is 234 used, when the packet arrives at PE2 it will contain no information 235 identifying the tunnel.) 236 When PE2 receives a packet over a pseudowire, it must be able to 237 determine that the packet was in fact received over a pseudowire, and 238 it must be able to associate that packet with a particular 239 pseudowire. PE2 is able to do this by examining the MPLS label which 240 serves as the pseudowire demultiplexor field shown in Figure 2. Call 241 this label the "PW label". 243 When PE1 sends a layer 2 PDU to PE2, it creates a MPLS packet by 244 adding the PW label to the packet, thus creating the first entry of 245 the label stack. If the PSN tunnel is an MPLS LSP the PE1 pushes 246 another label (the tunnel label) on to the packet as the second entry 247 of the label stack. The PW label is not visible again until the MPLS 248 packet reaches PE2. PE2's disposition of the packet is based on the 249 PW label. 251 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 252 the PW label will generally correspond to a particular ATM VC at PE2. 253 That is, PE2 needs to be able to infer from the PW label the outgoing 254 interface and the VPI/VCI value for the AAL5 PDU. If the payload is a 255 Frame Relay PDU, then PE2 needs to be able to infer from the PW label 256 the outgoing interface and the DLCI value. If the payload is an 257 Ethernet frame, then PE2 needs to be able to infer from the PW label 258 the outgoing interface, and perhaps the VLAN identifier. This process 259 is uni-directional, and will be repeated independently for bi- 260 directional operation. It is REQUIRED to assign the same PW ID, and 261 PW type for a given circuit in both directions. The group ID (see 262 below) MUST NOT be required to match in both directions. The 263 transported frame MAY be modified when it reaches the egress router. 264 If the header of the transported layer 2 frame is modified, this MUST 265 be done at the egress LSR only. Note that the PW label must always 266 be at the bottom of the packet's label stack and labels MUST be 267 allocated from the per-platform label space. 269 This document does not specify a method for distributing the MPLS 270 tunnel label or any other labels that may appear above the PW label 271 on the stack. Any acceptable method of MPLS label distribution will 272 do. This document specifies a protocol for assigning and distributing 273 the PW label. This protocol is LDP, extended as specified in the 274 remainder of this document. An LDP session must be set up between the 275 pseudowire endpoints. LDP MUST be used in its "downstream 276 unsolicited" mode. LDP's "liberal label retention" mode SHOULD be 277 used. 279 In addition to the protocol specified herein, static assignment of PW 280 labels may be used, and implementations of this protocol SHOULD 281 provide support for static assignment. 283 This document specifies all the procedures necessary to set up and 284 maintain the pseudowires needed to support "unswitched" point to 285 point services, where each endpoint of the pseudowire is provisioned 286 with the identify of the other endpoint. There are also protocol 287 mechanisms specified herein which can be used to support switched 288 services, and which can be used to support other provisioning models. 289 However, the use of the protocol mechanisms to support those other 290 models and services is not described in this document. 292 4. Details Specific to Particular Emulated Services 294 4.1. IP Layer2 Transport 296 This mode carries IP packets over a Pseudo-Wire. The encapsulation 297 used is according to [RFC3032]. The PW control word MAY be inserted 298 between the MPLS label stack and the IP payload. The encapsulation of 299 the IP packets for forwarding on the attachment circuit is 300 implementation specific, part of the NSP function [RFC3985], and is 301 outside the scope of this document. 303 5. LDP 305 The PW label bindings are distributed using the LDP downstream 306 unsolicited mode described in [LDP]. The PEs will establish an LDP 307 session using the Extended Discovery mechanism described in [LDP, 308 section 2.4.2 and 2.5]. 310 An LDP Label Mapping message contains a FEC TLV, a Label TLV, and 311 zero or more optional parameter TLVs. 313 The FEC TLV is used to indicate the meaning of the label. In the 314 current context, the FEC TLV would be used to identify the particular 315 pseudowire that a particular label is bound to. In this 316 specification, we define two new FEC TLVs to be used for identifying 317 pseudowires. When setting up a particular pseudowire, only one of 318 these FEC TLVs is used. The one to be used will depend on the 319 particular service being emulated and on the particular provisioning 320 model being supported. 322 LDP allows each FEC TLV to consist of a set of FEC elements. For 323 setting up and maintaining pseudowires, however, each FEC TLV MUST 324 contain exactly one FEC element. 326 The LDP base specification has several kinds of label TLVs, including 327 the Generic Label TLV as specified in [LDP] section 3.4.2.1. For 328 setting up and maintaining pseudowires, the Generic Label TLV MUST be 329 used. 331 5.1. LDP Extensions 333 This draft specifies no new LDP messages. 335 This draft specifies the following new TLVs to be used with LDP: 337 TLV Specified in Section Defined for Message 338 PW Status TLV 5.4.2 Notification 339 PW Interface Parameters TLV 5.3.2.1 FEC 340 PW Grouping ID TLV 5.3.2.2 FEC 342 Additionally the following new FEC element type are defined: 343 FEC element Type Specified in Section Defined for Message 344 0x80 5.2 FEC 345 0x81 5.3 FEC 347 The following new LDP error codes are also defined: 349 Status Code Specified in Section 350 "Illegal C-Bit" 6.1 351 "Wrong C-Bit" 6.2 352 "Incompatible bit-rate" [CEP] 353 "CEP/TDM mis-configuration" [CEP] 354 "PW status" 5.4.2 355 "Unassigned/Unrecognized TAI" 5.3.3 356 "Generic Misconfiguration Error" [SaTOP] 357 "Label Withdraw PW Status Method Not Supported" 5.4.1 359 5.2. The PWid FEC Element 361 The PWid FEC element may be used whenever both pseudowire endpoints 362 have been provisioned with the same 32-bit identifier for the 363 pseudowire. 365 For this purpose a new type of FEC element is defined. The FEC 366 element type is 0x80 [note1], and is defined as follows: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | PWid (0x80) |C| PW type |PW info Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Group ID | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | PW ID | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Interface Parameter Sub-TLV | 378 | " | 379 | " | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 - PW type 384 A 15 bit quantity containing a value which represents the type of 385 PW. Assigned Values are specified in "IANA Allocations for pseudo 386 Wire Edge to Edge Emulation (PWE3)" [IANA]. 388 - Control word bit (C) 390 The bit (C) is used to flag the presence of a control word as 391 follows: 393 C = 1 control word present on this PW. 394 C = 0 no control word present on this PW. 396 Please see the section "C-Bit Handling Procedures" for further 397 explanation. 399 - PW information length 401 Length of the PW ID field and the interface parameters sub-TLV in 402 octets. If this value is 0, then it references all PWs using the 403 specified group ID and there is no PW ID present, nor any 404 interface parameter sub-TLVs. 406 - Group ID 408 An arbitrary 32 bit value which represents a group of PWs that is 409 used to create groups in the PW space. The group ID is intended 410 to be used as a port index, or a virtual tunnel index. To 411 simplify configuration a particular PW ID at ingress could be 412 part of the virtual tunnel for transport to the egress router. 413 The Group ID is very useful to send wild card label withdrawals, 414 or PW wild card status notification messages to remote PEs upon 415 physical port failure. 417 - PW ID 419 A non-zero 32-bit connection ID that together with the PW type, 420 identifies a particular PW. Note that the PW ID and the PW type 421 MUST be the same at both endpoints. 423 - Interface Parameter Sub-TLV 425 This variable length TLV is used to provide interface specific 426 parameters, such as attachment circuit MTU. 428 Note that as the "interface parameter sub-TLV" are part of the 429 FEC, the rules of LDP make it impossible to change the interface 430 parameters once the pseudowire has been set up. Thus the 431 interface parameters field must not be used to pass information, 432 such as status information, which may change during the life of 433 the pseudowire. Optional parameter TLVs should be used for that 434 purpose. 436 Using the PWid FEC, each of the two pseudowire endpoints 437 independently initiates the set up of a unidirectional LSP. An 438 outgoing LSP and an incoming LSP are bound together into a single 439 pseudowire if they have the same PW ID and PW type. 441 5.3. The Generalized PWid FEC Element 443 The PWid FEC element can be used if a unique 32-bit value has been 444 assigned to the PW, and if each endpoint has been provisioned with 445 that value. The Generalized PWid FEC element requires that the PW 446 endpoints be uniquely identified; the PW itself is identified as a 447 pair of endpoints. In addition the endpoint identifiers are 448 structured to support applications where the identity of the remote 449 endpoints needs to be auto-discovered rather than statically 450 configured. 452 The "Generalized PWid FEC Element" is FEC type 0x81 (provisionally, 453 subject to assignment by IANA). 455 The Generalized PWid FEC Element does not contain anything 456 corresponding to the "Group ID" of the PWid FEC element. The 457 functionality of the "Group ID" is provided by a separate optional 458 LDP TLV, the "PW Grouping TLV", described below. The Interface 459 Parameters field of the PWid FEC element is also absent; its 460 functionality is replaced by the optional Interface Parameters TLV, 461 described below. 463 5.3.1. Attachment Identifiers 465 As discussed in [RFC3985], a pseudowire can be thought of as 466 connecting two "forwarders". The protocol used to setup a pseudowire 467 must allow the forwarder at one end of a pseudowire to identify the 468 forwarder at the other end. We use the term "attachment identifier", 469 or "AI", to refer to the field which the protocol uses to identify 470 the forwarders. In the PWid FEC, the PWid field serves as the AI. 471 In this section we specify a more general form of AI which is 472 structured and of variable length. 474 Every Forwarder in a PE must be associated with an Attachment 475 Identifier (AI), either through configuration or through some 476 algorithm. The Attachment Identifier must be unique in the context of 477 the PE router in which the Forwarder resides. The combination must be globally unique. 480 It is frequently convenient to regard a set of Forwarders as being 481 members of a particular "group", where PWs may only be set up among 482 members of a group. In such cases, it is convenient to identify the 483 Forwarders relative to the group, so that an Attachment Identifier 484 would consist of an Attachment Group Identifier (AGI) plus an 485 Attachment Individual Identifier (AII). 487 An Attachment Group Identifier may be thought of as a VPN-id, or a 488 VLAN identifier, some attribute which is shared by all the Attachment 489 PWs (or pools thereof) which are allowed to be connected. 491 The details of how to construct the AGI and AII fields identifying 492 the pseudowire endpoints are outside the scope of this specification. 493 Different pseudowire application, and different provisioning models, 494 will require different sorts of AGI and AII fields. The 495 specification of each such application and/or model must include the 496 rules for constructing the AGI and AII fields. 498 As previously discussed, a (bidirectional) pseudowire consists of a 499 pair of unidirectional LSPs, one in each direction. If a particular 500 pseudowire connects PE1 with PE2, the PW direction from PE1 to PE2 501 can be identified as: 503 , PE2, >, 505 and the PW direction from PE2 to PE1 can be identified by: 507 , PE1, >. 509 Note that the AGI must be the same at both endpoints, but the AII 510 will in general be different at each endpoint. Thus from the 511 perspective of a particular PE, each pseudowire has a local or 512 "Source AII", and a remote or "Target AII". The pseudowire setup 513 protocol can carry all three of these quantities: 515 - Attachment Group Identifier (AGI). 517 - Source Attachment Individual Identifier (SAII) 519 - Target Attachment Individual Identifier (TAII) 521 If the AGI is non-null, then the Source AI (SAI) consists of the AGI 522 together with the SAII, and the Target AI (TAI) consists of the TAII 523 together with the AGI. If the AGI is null, then the SAII and TAII 524 are the SAI and TAI respectively. 526 The interpretation of the SAI and TAI is a local matter at the 527 respective endpoint. 529 The association of two unidirectional LSPs into a single 530 bidirectional pseudowire depends on the SAI and the TAI. Each 531 application and/or provisioning model which uses the Generalized ID 532 FEC element must specify the rules for performing this association. 534 5.3.2. Encoding the Generalized ID FEC Element 536 FEC element type 0x81 [note1] is used. The FEC element is encoded 537 as follows: 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |Gen PWid (0x81)|C| PW Type |PW info Length | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | AGI Type | Length | Value | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 ~ AGI Value (contd.) ~ 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | AII Type | Length | Value | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 ~ SAII Value (contd.) ~ 552 | | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | AII Type | Length | Value | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 ~ TAII Value (contd.) ~ 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 This document does not specify the AII, and AGI type field values; 561 specification of the type field values to use for a particular 562 application is part of the specification of that application. IANA 563 will assign these values using the method defined in the [IANA] 564 document. 566 The SAII, TAII, and AGI are simply carried as octet strings. The 567 length byte specifies the size of the Value field. The null string 568 can be sent by setting the length byte to 0. If a particular 569 application does not need all three of these sub-elements, it MUST 570 send all the sub-elements, but set the length to 0 for the unused 571 sub-elements. 573 The PW information length field, contains the length of the SAII, 574 TAII and, AGI combined in octets. If this value is 0, then it 575 references all PWs using the specified grouping ID. In this case 576 there are no other FEC element fields (AGI,SAII, etc. ) present, nor 577 any interface parameters TLVs. 579 Note that the interpretation of a particular field as AGI, SAII, or 580 TAII depends on the order of its occurrence. The type field 581 identifies the type of the AGI, SAII, or TAII. When comparing two 582 occurrences of an AGI (or SAII or TAII), the two occurrences are 583 considered to be identical if the type, length, and value fields of 584 one are identical, respectively, to those of the other. 586 5.3.2.1. Interface Parameters TLV 588 This TLV MUST only be used when sending the Generalized PW FEC. It 589 specifies interface specific parameters. Specific parameters, when 590 applicable, MUST be used to validate that the PEs, and the ingress 591 and egress ports at the edges of the circuit, have the necessary 592 capabilities to interoperate with each other. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 |0|0| PW Intf P. TLV (0x096B) | Length | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Sub-TLV Type | Length | Variable Length Value | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Variable Length Value | 602 | " | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 [ note: TLV type 0x096B pending IANA allocation ] 607 A more detailed description of this field can be found in the section 608 "Interface Parameters Sub-TLV" below. 610 5.3.2.2. PW Grouping TLV 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 |0|0|PW Grouping ID TLV (0x096C)| Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Value | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 [ note: TLV type 0x096C pending IANA allocation ] 622 The PW Grouping ID is an arbitrary 32 bit value which represents an 623 arbitrary group of PWs. It is used create groups PWs; for example, a 624 PW Grouping ID can be used as a port index, and assigned to all PWs 625 that lead to that port. Use of the PW Grouping ID enables one to 626 send "wild card" label withdrawals, or "wild card" status 627 notification messages to remote PEs upon physical port failure. 629 Note Well: The PW Grouping ID is different than, and has no relation 630 to, the Attachment Group Identifier. 632 The PW Grouping ID TLV is not part of the FEC, and will not be 633 advertised except in the PW FEC advertisement. The advertising PE MAY 634 use the wild card withdraw semantics, but the remote PEs MUST 635 implement support for wildcard messages. This TLV MUST only be used 636 when sending the Generalized PW ID FEC. 638 To issue a wildcard command (status or withdraw): 640 - Set the PW Info Length to 0 in the Generalized ID FEC Element. 641 - Send only the PW Grouping ID TLV with the FEC (No AGI/SAII/TAII 642 is sent). 644 5.3.3. Signaling Procedures 646 In order for PE1 to begin signaling PE2, PE1 must know the address of 647 the remote PE2, and a TAI. This information may have been configured 648 at PE1, or it may have been learned dynamically via some 649 autodiscovery procedure. 651 The egress PE (PE1), that has knowledge of the ingress PE, initiates 652 the setup by sending a Label Mapping Message to the ingress PE (PE2). 653 The Label Mapping message contains the FEC TLV, carrying the 654 Generalized PWid FEC Element (type 0x81). The Generalized PWid FEC 655 element contains the AGI, SAII and TAII information. 657 Next when PE2 receives such a Label Mapping message, PE2 interprets 658 the message as a request to set up a PW whose endpoint (at PE2) is 659 the Forwarder identified by the TAI. From the perspective of the 660 signaling protocol, exactly how PE2 maps AIs to Forwarders is a local 661 matter. In some Virtual Private Wire Services (VPWS) provisioning 662 models, the TAI might, e.g., be a string which identifies a 663 particular Attachment Circuit, such as "ATM3VPI4VCI5", or it might, 664 e.g., be a string such as "Fred" which is associated by configuration 665 with a particular Attachment Circuit. In VPLS, the AGI could be a 666 VPN-id, identifying a particular VPLS instance. 668 If PE2 cannot map the TAI to one of its Forwarders, then PE2 sends a 669 Label Release message to PE1, with a Status Code of 670 "Unassigned/Unrecognized TAI" , and the processing of the Label 671 Mapping message is complete. 673 [ note: Status Code 0x00000029 "Unassigned/Unrecognized TAI" as 674 defined in [IANA] pending IANA allocation ] 676 The FEC TLV sent in a Label Release message is the same as the FEC 677 TLV received in the Label Mapping being released (but without the 678 interface parameter TLV). More generally, the FEC TLV is the same in 679 all LDP messages relating to the same PW. In a Label Release this 680 means that the SAII is the remote peer's AII and the TAII is the 681 sender's local AII. 683 If the Label Mapping Message has a valid TAI, PE2 must decide whether 684 to accept it or not. The procedures for so deciding will depend on 685 the particular type of Forwarder identified by the TAI. Of course, 686 the Label Mapping message may be rejected due to standard LDP error 687 conditions as detailed in [LDP]. 689 If PE2 decides to accept the Label Mapping message, then it has to 690 make sure that an PW LSP is set up in the opposite (PE1-->PE2) 691 direction. If it has already signaled for the corresponding PW LSP 692 in that direction, nothing more need be done. Otherwise, it must 693 initiate such signaling by sending a Label Mapping message to PE1. 694 This is very similar to the Label Mapping message PE2 received, but 695 with the SAI and TAI reversed. 697 Thus a bidirectional PW consists of two LSPs, where the FEC of one 698 has the SAII and TAII reversed wiht respect of the FEC of the other. 700 5.4. Signaling of Pseudo Wire Status 702 5.4.1. Use of Label Mappings Messages. 704 The PEs MUST send Label Mapping Messages to their peers as soon as 705 the PW is configured and administratively enabled, regardless of the 706 attachment circuit state. The PW label should not be withdrawn unless 707 the operator administratively configures the pseudo wire down (or the 708 PW configuration is deleted entirely). Using the procedures outlined 709 in this section a simple label withdraw method MAY also be supported 710 as a legacy means of signaling PW status and AC status. In any case 711 if the label-to-PW binding is not available the PW MUST be considered 712 in the down state. 714 Once, the PW status negotiation procedures are completed and if they 715 result in the use of the label withdraw method for PW status 716 communication, and this method is not supported by one of the PEs, 717 than that PE must send a Label Release Message to its peer with the 718 following error: 720 "Label Withdraw PW Status Method Not Supported" 722 If the label withdraw method for PW status communication is selected 723 for the PW, it will result in the Label Mapping Message being 724 advertised only if the attachment circuit is active. The PW status 725 signaling procedures described in this section MUST be fully 726 implemented. 728 5.4.2. Signaling PW status. 730 The PE devices use an LDP TLV to indicate status to their remote 731 peers. This PW Status TLV contains more information than the 732 alternative simple Label Withdraw message. 734 The format of the PW Status TLV is: 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |1|0| PW Status (0x096A) | Length | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Status Code | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 [ note: TLV type 0x096A pending IANA allocation ] 745 Where the status code is a 4 octet bit field is specified in the PW 746 IANA Allocations document [IANA]. The length specifies the length of 747 the Status Code field in octets (equal to 4). 749 Each bit in the status code field can be set individually to indicate 750 more then a single failure at once. Each fault can be cleared by 751 sending an appropriate Notification message with the respective bit 752 cleared. The presence of the lowest bit (PW Not Forwarding) acts only 753 as a generic failure indication when there is a link-down event for 754 which none of the other bits apply. 756 The Status TLV is transported to the remote PW peer via the LDP 757 Notification message. The general format of the Notification Message 758 is: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |0| Notification (0x0001) | Message Length | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Message ID | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Status (TLV) | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | PW Status TLV | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | PWId FEC TLV or Generalized ID FEC TLV | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 The Status TLV status code is set to 0x00000028 "PW status", to 775 indicate that PW status follows. Since this notification does not 776 refer to any particular message the Message Id, and Message Type 777 fields are set to 0. [ note: Status Code 0x00000028 as defined in 778 [IANA] pending IANA allocation ] 780 The PW FEC TLV SHOULD not include the interface parameter sub-TLVs as 781 they are ignored in the context of this message. When a PE's 782 attachment circuit encounters an error, use of the PW Notification 783 Message allows the PE to send a single "wild card" status message, 784 using a PW FEC TLV with only the group ID set, to denote this change 785 in status for all affected PW connections. This status message 786 contains either the PW FEC TLV with only the group ID set, or else it 787 contains the Generalized FEC TLV with only the PW Grouping ID TLV. 789 As mentioned above the Group ID field of the PWid FEC element, or the 790 PW Grouping ID TLV used with the Generalized ID FEC element, can be 791 used to send a status notification for all arbitrary sets of PWs. 792 This procedure is OPTIONAL, and if it is implemented the LDP 793 Notification message should be as follows: If the PWid FEC element is 794 used, the PW information length field is set to 0, the PW ID field is 795 not present, and the interface parameter sub-TLVs are not present. If 796 the Generalized FEC element is used, the AGI, SAII, and TAII are not 797 present,the PW information length field is set to 0, the PW Grouping 798 ID TLV is included, and the Interface Parameters TLV is omitted. For 799 the purpose of this document this is called the "wild card PW status 800 notification procedure", and all PEs implementing this design are 801 REQUIRED to accept such a notification message, but are not required 802 to send it. 804 5.4.3. Pseudowire Status Negotiation Procedures 806 When a PW is first set up the PEs MUST attempt to negotiate the usage 807 of the PW status TLV. This is accomplished as follows: A PE that 808 supports the PW Status TLV MUST include it the initial Label Mapping 809 message following the PW FEC, and the interface parameter sub-TLVs. 810 The PW Status TLV will then be used for the lifetime of the 811 Pseudowire. This is shown in the following diagram: 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | | 817 + PWId FEC or Generalized ID FEC + 818 | | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Interface Parameters | 821 | " | 822 | " | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 |0|0| Generic Label (0x0200) | Length | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Label | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 |1|0| PW Status (0x0???) | Length | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Status Code | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 If a PW Status TLV is included in the initial Label Mapping message 834 for a PW then if the Label Mapping message from the remote PE for 835 that PW does not include a PW status TLV or if the remote PE does not 836 support the PW Status TLV the PW will revert to the label withdraw 837 method of signaling PW status. Note that if the PW Status TLV is not 838 supported by the remote peer the peer will automatically ignore it 839 since the I(ignore) bit is set in the TLV. The PW Status TLV, 840 therefore, will not be present in the corresponding FEC advertisement 841 from the remote LDP peer resulting in exactly the above behavior. 843 If the PW Status TLV is not present following the FEC TLV in the 844 initial PW Label Mapping message received by a PE, then the PW Status 845 TLV will not be used and both PEs supporting the pseudowire will 846 revert to the label withdraw procedure for signaling status changes. 848 If the negotiation process results in the usage of the PW status TLV, 849 then the actual PW status is determined by the PW status TLV that was 850 sent within the initial PW Label Mapping message. Subsequent updates 851 of PW status are conveyed through the notification message 853 5.5. Interface Parameters sub-TLV 855 This field specifies interface specific parameters. When applicable, 856 it MUST be used to validate that the PEs, and the ingress and egress 857 ports at the edges of the circuit, have the necessary capabilities to 858 interoperate with each other. The field structure is defined as 859 follows: 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Sub-TLV Type | Length | Variable Length Value | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Variable Length Value | 867 | " | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 The interface paramater sub-TLV type values are specified in "IANA 871 Allocations for pseudo Wire Edge to Edge Emulation (PWE3)" [IANA]. 873 The Length field is defined as the length of the interface parameter 874 including the parameter id and length field itself. Processing of the 875 interface parameters should continue when encountering unknown 876 interface parameters and they MUST be silently ignored. 878 - Interface MTU sub-TLV type 880 A 2 octet value indicating the MTU in octets. This is the Maximum 881 Transmission Unit, excluding encapsulation overhead, of the 882 egress packet interface that will be transmitting the 883 decapsulated PDU that is received from the MPLS enabled network. 884 This parameter is applicable only to PWs transporting packets and 885 is REQUIRED for these PW types. If this parameter does not match 886 in both directions of a specific PW, that PW MUST NOT be enabled. 888 - Optional Interface Description string sub-TLV type 890 This arbitrary, OPTIONAL, interface description string is used to 891 send a human-readable administrative string describing the 892 interface to the remote. This parameter is OPTIONAL, and is 893 applicable to all PW types. The interface description parameter 894 string length is variable, and can be from 0 to 80 octets. 895 Human-readable text MUST be provided in the UTF-8 charset using 896 the Default Language [RFC2277]. 898 6. Control Word 900 6.1. PW types for which the control word is REQUIRED 902 The Label Mapping messages which are sent in order to set up these 903 PWs MUST have c=1. When a Label Mapping message for a PW of one of 904 these types is received, and c=0, a Label Release message MUST be 905 sent, with an "Illegal C-bit" status code. In this case, the PW will 906 not be enabled. 908 6.2. PW types for which the control word is NOT mandatory 910 If a system is capable of sending and receiving the control word on 911 PW types for which the control word is not mandatory, then each such 912 PW endpoint MUST be configurable with a parameter that specifies 913 whether the use of the control word is PREFERRED or NOT PREFERRED. 914 For each PW, there MUST be a default value of this parameter. This 915 specification does NOT state what the default value should be. 917 If a system is NOT capable of sending and receiving the control word 918 on PW types for which the control word is not mandatory, then it 919 behaves exactly as if it were configured for the use of the control 920 word to be NOT PREFERRED. 922 If a Label Mapping message for the PW has already been received, but 923 no Label Mapping message for the PW has yet been sent, then the 924 procedure is the following: 926 -i. If the received Label Mapping message has c=0, send a Label 927 Mapping message with c=0, and the control word is not used. 928 -ii. If the received Label Mapping message has c=1, and the PW is 929 locally configured such that the use of the control word is 930 preferred, then send a Label Mapping message with c=1, and 931 the control word is used. 932 -iii. If the received Label Mapping message has c=1, and the PW is 933 locally configured such that the use of the control word is 934 not preferred or the control word is not supported, then act 935 as if no Label Mapping message for the PW had been received 936 (i.e., proceed to the next paragraph). 938 If a Label Mapping message for the PW has not already been received 939 (or if the received Label Mapping message had c=1 and either local 940 configuration says that the use of the control word is not preferred 941 or the control word is not supported), then send a Label Mapping 942 message in which the c bit is set to correspond to the locally 943 configured preference for use of the control word. (I.e., set c=1 if 944 locally configured to prefer the control word, set c=0 if locally 945 configured to prefer not to use the control word or if the control 946 word is not supported). 948 The next action depends on what control message is next received for 949 that PW. The possibilities are: 951 -i. A Label Mapping message with the same c bit value as 952 specified in the Label Mapping message that was sent. PW 953 setup is now complete, and the control word is used if c=1 954 but not used if c=0. 955 -ii. A Label Mapping message with c=1, but the Label Mapping 956 message that was sent has c=0. In this case, ignore the 957 received Label Mapping message, and continue to wait for the 958 next control message for the PW. 959 -iii. A Label Mapping message with c=0, but the Label Mapping 960 message that was sent has c=1. In this case, send a Label 961 Withdraw message with a "Wrong C-bit" status code, followed 962 by a Label Mapping message that has c=0. PW setup is now 963 complete, and the control word is not used. 964 -iv. A Label Withdraw message with the "Wrong c-bit" status code. 965 Treat as a normal Label Withdraw, but do not respond. 966 Continue to wait for the next control message for the PW. 968 If at any time after a Label Mapping message has been received, a 969 corresponding Label Withdraw or Release is received, the action taken 970 is the same as for any Label Withdraw or Release that might be 971 received at any time. 973 If both endpoints prefer the use of the control word, this procedure 974 will cause it to be used. If either endpoint prefers not to use the 975 control word, or does not support the control word, this procedure 976 will cause it not to be used. If one endpoint prefers to use the 977 control word but the other does not, the one that prefers not to use 978 it is has no extra protocol to execute, it just waits for a Label 979 Mapping message that has c=0. 981 The diagram in Appendix A illustrates the above procedure. 983 6.3. LDP label Withdrawal procedures 985 As mentioned above, the Group ID field of the PWid FEC element, or 986 the PW Grouping ID TLV used with the Generalized ID FEC element, can 987 be used to withdraw all PW labels associated with a particular PW 988 group. This procedure is OPTIONAL, and if it is implemented the LDP 989 Label Withdraw message should be as follows: If the PWid FEC element 990 is used, the PW information length field is set to 0, the PW ID field 991 is not present, and the interface parameter sub-TLVs are not present. 993 If the Generalized FEC element is used, the AGI, SAII, and TAII are 994 not present,the PW information length field is set to 0, the PW 995 Grouping ID TLV is included, and the Interface Parameters TLV is 996 omitted. For the purpose of this document this is called the "wild 997 card withdraw procedure", and all PEs implementing this design are 998 REQUIRED to accept such withdrawn message, but are not required to 999 send it. Note that the PW Grouping ID TLV only applies to PW using 1000 the Generalized ID FEC element, while the Group ID only applies to 1001 PWid FEC element. 1003 The interface parameter sub-TLVs, or TLV, MUST NOT be present in any 1004 LDP PW Label Withdraw or Label Release message. A wildcard Label 1005 Release message MUST include only the group ID, or Grouping ID TLV. A 1006 Label Release message initiated a PE router must always include the 1007 PW ID. 1009 6.4. Sequencing Considerations 1011 In the case where the router considers the sequence number field in 1012 the control word, it is important to note the following when 1013 advertising labels 1015 6.4.1. Label Advertisements 1017 After a label has been withdrawn by the output router and/or released 1018 by the input router, care must be taken to not advertise (re-use) the 1019 same released label until the output router can be reasonably certain 1020 that old packets containing the released label no longer persist in 1021 the MPLS enabled network. 1023 This precaution is required to prevent the imposition router from 1024 restarting packet forwarding with sequence number of 1 when it 1025 receives a Label Mapping message that binds the same FEC to the same 1026 label if there are still older packets persisting in the network with 1027 sequence number between 1 and 32768. For example, if there is a 1028 packet with sequence number=n where n is in the interval[1,32768] 1029 traveling through the network, it would be possible for the 1030 disposition router to receive that packet after it re-advertises the 1031 label. Since the label has been released by the imposition router, 1032 the disposition router SHOULD be expecting the next packet to arrive 1033 with sequence number to be 1. Receipt of a packet with sequence 1034 number equal to n will result in n packets potentially being rejected 1035 by the disposition router until the imposition router imposes a 1036 sequence number of n+1 into a packet. Possible methods to avoid this 1037 is for the disposition router to always advertise a different PW 1038 label, or for the disposition router to wait for a sufficient time 1039 before attempting to re-advertised a recently released label. This is 1040 only an issue when sequence number processing at the disposition 1041 router is enabled. 1043 6.4.2. Label Release 1045 In situations where the imposition router wants to restart forwarding 1046 of packets with sequence number 1, the router shall 1) Send to 1047 disposition router a Label Release Message, and 2) Send to 1048 disposition router a Label Request message. When sequencing is 1049 supported, advertisement of a PW label in response to a Label Request 1050 message MUST also consider the issues discussed in the section on 1051 Label Advertisements. 1053 7. IANA Considerations 1055 7.1. LDP TLV TYPE 1057 This document uses several new LDP TLV types, IANA already maintains 1058 a registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The 1059 following values are suggested for assignment: 1061 TLV type Description 1062 0x096A PW Status TLV 1063 0x096B PW Interface Parameters TLV 1064 0x096C Group ID TLV 1066 7.2. LDP Status Codes 1068 This document uses several new LDP status codes, IANA already 1069 maintains a registry of name "STATUS CODE NAME SPACE" defined by 1070 RFC3036. The following values are suggested for assignment: 1072 0x00000024 "Illegal C-Bit" 1073 0x00000025 "Wrong C-Bit" 1074 0x00000026 "Incompatible bit-rate" 1075 0x00000027 "CEP/TDM mis-configuration" 1076 0x00000028 "PW status" 1077 0x00000029 "Unassigned/Unrecognized TAI" 1078 0x0000002A "Generic Misconfiguration Error" 1079 0x0000002B "Label Withdraw PW Status Method Not Supported" 1081 7.3. FEC Type Name Space 1083 This document uses two new FEC element types, 0x80 and 0x81 from the 1084 registry "FEC Type Name Space" for the Label Distribution Protocol 1085 (LDP RFC3036). 1087 8. Security Considerations 1089 This document specifies the LDP extensions that are needed for 1090 setting up and maintaining Pseudowires. The purpose of setting up 1091 Pseudowires is to enable layer 2 frames to be encapsulated in MPLS 1092 and transmitted from one end of a Pseudowire to the other. Therefore 1093 we treat the security considerations for both the data plane and the 1094 control plane. 1096 8.1. Data-plane Security 1098 With regard to the security of the data plane, the following areas 1099 must be considered: 1101 - MPLS PDU inspection. 1102 - MPLS PDU spoofing. 1103 - MPLS PDU alteration. 1104 - MPLS PSN protocol security. 1105 - Access Circuit security. 1106 - Denial of service prevention on the PE routers. 1108 When a MPLS PSN is used to provide pseudowire service, there is a 1109 perception that security MUST be at least equal to the currently 1110 deployed layer2 native protocol networks that the MPLS/PW network 1111 combination is emulating. This means that the MPLS enabled network 1112 SHOULD be isolated from outside packet insertion in such a way that 1113 it SHOULD not be possible to directly insert an MPLS packet into the 1114 network. To prevent unwanted packet insertion, it is also important 1115 to prevent unauthorized physical access to the PSN as well as 1116 unauthorized administrative access to individual network elements. 1118 As mentioned above, as MPLS enabled network, should not accept MPLS 1119 packets from its external interfaces (i.e. interfaces to CE devices 1120 or to other providers' networks) unless the top label of the packet 1121 was legitimately distributed to the system from which the packet is 1122 being received. If the packet's incoming interface leads to a 1123 different SP (rather than to a customer), an appropriate trust 1124 relationship must also be present, including the trust that the other 1125 SP also provides appropriate security measures. 1127 The three main security problems faced when using an MPLS enabled 1128 network to transport PWs are spoofing, alteration, and inspection. 1129 First there is a possibility that the PE receiving PW PDUs will get a 1130 PDU which appears to be from the PE transmitting the PW into the PSN, 1131 but which was not actually transmitted by the PE originating the PW. 1132 (I.e., the specified encapsulations do not by themselves enable the 1133 decapsulator to authenticate the encapsulator.) A second problem is 1134 the possibility that the PW PDU will be altered between the time it 1135 enters PSN and the time it leaves the PSN. (I.e., the specified 1136 encapsulations do not by themselves assure the decapsulator of the 1137 packet's integrity.) A third problem is the possibility that the 1138 PDU's contents will be seen while the PDU is in transit through the 1139 PSN. (I.e., the specification encapsulations do not ensure privacy.) 1140 How significant these issues are in practice depends on the security 1141 requirements of the applications whose traffic is being sent through 1142 the tunnel, and how secure is the PSN itself. 1144 8.2. Control Protocol Security 1146 General security considerations with regard to the use of LDP are 1147 specified in section 5 of RFC 3036. Those considerations apply as 1148 well to the case where LDP is used to set up Pseudowires. 1150 A Pseudowire connects two attachment circuits. It is important to 1151 make sure that LDP connections are not arbitrarily accepted from 1152 anywhere, or else a local attachment circuit might get connected to 1153 an arbitrary remote attachment circuit. Therefore an incoming LDP 1154 session request MUST NOT be accepted unless its IP source address is 1155 known to be the source of an "eligible" LDP peer. The set of 1156 eligible peers could be pre-configured (either as a list of IP 1157 addresses, or as a list of address/mask combinations), or it could be 1158 discovered dynamically via an auto-discovery protocol which is itself 1159 trusted. (Obviously if the auto-discovery protocol were not trusted, 1160 the set of "eligible peers" it produces could not be trusted.) 1162 Even if an LDP connection request appears to come from an eligible 1163 peer, its source address may have been spoofed. So some means of 1164 preventing source address spoofing must be in place. For example, if 1165 all the eligible peers are in the same network, source address 1166 filtering at the border routers of that network could eliminate the 1167 possibility of source address spoofing. 1169 The LDP MD5 authentication key option, as described in section 2.9 of 1170 RFC 3036, MUST be implemented, and for a greater degree of security 1171 it must be used. This provides integrity and authentication for the 1172 LDP messages, and eliminates the possibility of source address 1173 spoofing. Use of the MD5 option does not provide privacy, but privacy 1174 of the LDP control messages is not usually considered to be 1175 important. As the MD5 option relies on the configuration of pre- 1176 shared keys, it does not provide much protection against replay 1177 attacks. In addition, its reliance on pre-shared keys may make it 1178 very difficult to deploy when the set of eligible neighbors is 1179 determined by an auto-configuration protocol. 1181 When the Generalized ID FEC Element is used, it is possible that a 1182 particular LDP peer may be one of the eligible LDP peers, but may not 1183 be the right one to connect to the particular attachment circuit 1184 identified by the particular instance of the Generalized ID FEC 1185 element. However, given that the peer is known to be one of the 1186 eligible peers (as discussed above), this would be the result of a 1187 configuration error, rather than a security problem. Nevertheless, 1188 it may be advisable for a PE to associate each of its local 1189 attachment circuits with a set of eligible peers, rather than having 1190 just a single set of eligible peers associated with the PE as a 1191 whole. 1193 9. Intellectual Property Statement 1195 The IETF takes no position regarding the validity or scope of any 1196 Intellectual Property Rights or other rights that might be claimed to 1197 pertain to the implementation or use of the technology described in 1198 this document or the extent to which any license under such rights 1199 might or might not be available; nor does it represent that it has 1200 made any independent effort to identify any such rights. Information 1201 on the procedures with respect to rights in RFC documents can be 1202 found in BCP 78 and BCP 79. 1204 Copies of IPR disclosures made to the IETF Secretariat and any 1205 assurances of licenses to be made available, or the result of an 1206 attempt made to obtain a general license or permission for the use of 1207 such proprietary rights by implementers or users of this 1208 specification can be obtained from the IETF on-line IPR repository at 1209 http://www.ietf.org/ipr. 1211 The IETF invites any interested party to bring to its attention any 1212 copyrights, patents or patent applications, or other proprietary 1213 rights that may cover technology that may be required to implement 1214 this standard. Please address the information to the IETF at ietf- 1215 ipr@ietf.org. 1217 10. Full Copyright Statement 1219 Copyright (C) The Internet Society (2005). This document is subject 1220 to the rights, licenses and restrictions contained in BCP 78, and 1221 except as set forth therein, the authors retain all their rights. 1223 This document and the information contained herein are provided on an 1224 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1225 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1226 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1227 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1228 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1229 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1231 11. Acknowledgments 1233 The authors wish to acknowledge the contributions of Vach Kompella, 1234 Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds. 1236 12. Normative References 1238 [LDP] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 1239 Fredette, B. Thomas. January 2001. RFC3036 1241 [RFC3032] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, 1242 D. Tappan, G. Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 1244 [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation 1245 (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt 1246 (work in progress), April 2004 1248 13. Informative References 1250 [CEP] "SONET/SDH Circuit Emulation Service Over Packet (CEP)", 1251 draft-ietf-pwe3-sonet-11.txt (work in progress) 1253 [SAToP] "Structure-Agnostic TDM over Packet (SAToP)", 1254 draft-ietf-pwe3-satop-01.txt (work in progress) 1256 [FRAME] "Frame Relay over Pseudo-Wires", 1257 draft-ietf-pwe3-frame-relay-02.txt (work in progress ) 1259 [ATM] "Encapsulation Methods for Transport of ATM Cells/Frame Over IP 1260 and MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt (work in 1261 progress) 1263 [PPPHDLC] "Encapsulation Methods for Transport of PPP/HDLC Frames 1264 Over IP and MPLS Networks", 1265 draft-ietf-pwe3-hdlc-ppp-encap-05.txt (work in progress) 1267 [ETH] "Encapsulation Methods for Transport of Ethernet Frames Over 1268 IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-06.txt. 1269 (work in progress) 1271 [802.3] "IEEE 802.3ac-1998" IEEE standard specification. 1273 [SDH] American National Standards Institute, "Synchronous Optical 1274 Network Formats," ANSI T1.105-1995. 1276 [ITUG] ITU Recommendation G.707, "Network Node Interface For The 1277 Synchronous Digital Hierarchy", 1996. 1279 [RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985. 1281 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1282 IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1283 1998. 1285 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1286 Languages", BCP 18, RFC 2277, January 1998. 1288 [note1] FEC element type 0x80,0x81 is pending IANA approval. 1290 14. Author Information 1292 Luca Martini 1293 Cisco Systems, Inc. 1294 9155 East Nichols Avenue, Suite 400 1295 Englewood, CO, 80112 1296 e-mail: lmartini@cisco.com 1298 Nasser El-Aawar 1299 Level 3 Communications, LLC. 1300 1025 Eldorado Blvd. 1301 Broomfield, CO, 80021 1302 e-mail: nna@level3.net 1303 Giles Heron 1304 Tellabs 1305 Abbey Place 1306 24-28 Easton Street 1307 High Wycombe 1308 Bucks 1309 HP11 1NT 1310 UK 1311 e-mail: giles.heron@tellabs.com 1313 Eric C. Rosen 1314 Cisco Systems, Inc. 1315 1414 Massachusetts Avenue 1316 Boxborough, MA 01719 1317 e-mail: erosen@cisco.com 1319 Dan Tappan 1320 Cisco Systems, Inc. 1321 1414 Massachusetts Avenue 1322 Boxborough, MA 01719 1323 e-mail: tappan@cisco.com 1325 Toby Smith 1326 Omega Corporate Center 1327 1300 Omega Drive 1328 Pittsburgh, PA 15205 1329 Laurel Networks, Inc. 1330 e-mail: tob@laurelnetworks.com 1332 15. Additional Contributing Authors 1334 Dimitri Stratton Vlachos 1335 Mazu Networks, Inc. 1336 125 Cambridgepark Drive 1337 Cambridge, MA 02140 1338 e-mail: d@mazunetworks.com 1339 Jayakumar Jayakumar, 1340 Cisco Systems Inc. 1341 225, E.Tasman, MS-SJ3/3, 1342 San Jose, CA, 95134 1343 e-mail: jjayakum@cisco.com 1345 Alex Hamilton, 1346 Cisco Systems Inc. 1347 285 W. Tasman, MS-SJCI/3/4, 1348 San Jose, CA, 95134 1349 e-mail: tahamilt@cisco.com 1351 Steve Vogelsang 1352 Laurel Networks, Inc. 1353 Omega Corporate Center 1354 1300 Omega Drive 1355 Pittsburgh, PA 15205 1356 e-mail: sjv@laurelnetworks.com 1358 John Shirron 1359 Omega Corporate Center 1360 1300 Omega Drive 1361 Pittsburgh, PA 15205 1362 Laurel Networks, Inc. 1363 e-mail: jshirron@laurelnetworks.com 1365 Andrew G. Malis 1366 Tellabs 1367 90 Rio Robles Dr. 1368 San Jose, CA 95134 1369 e-mail: Andy.Malis@tellabs.com 1371 Vinai Sirkay 1372 Reliance Infocomm 1373 Dhirubai Ambani Knowledge City 1374 Navi Mumbai 400 709 1375 e-mail: vinai@sirkay.com 1376 Vasile Radoaca 1377 Nortel Networks 1378 600 Technology Park 1379 Billerica MA 01821 1380 e-mail: vasile@nortelnetworks.com 1382 Chris Liljenstolpe 1383 Cable & Wireless 1384 11700 Plaza America Drive 1385 Reston, VA 20190 1386 e-mail: chris@cw.net 1388 Dave Cooper 1389 Global Crossing 1390 960 Hamlin Court 1391 Sunnyvale, CA 94089 1392 e-mail: dcooper@gblx.net 1394 Kireeti Kompella 1395 Juniper Networks 1396 1194 N. Mathilda Ave 1397 Sunnyvale, CA 94089 1398 e-mail: kireeti@juniper.net 1400 Ap A C-bit Handling Procedures Diagram 1402 ------------------ 1403 Y | Received Label | N 1404 -------| Mapping Msg? |-------------- 1405 | ------------------ | 1406 -------------- | 1407 | | | 1408 ------- ------- | 1409 | C=0 | | C=1 | | 1410 ------- ------- | 1411 | | | 1412 | ---------------- | 1413 | | Control Word | N | 1414 | | Capable? |----------- | 1415 | ---------------- | | 1416 | Y | | | 1417 | | | | 1418 | ---------------- | | 1419 | | Control Word | N | | 1420 | | Preferred? |---- | | 1421 | ---------------- | | | 1422 | Y | | | | 1423 | | | | ---------------- 1424 | | | | | Control Word | 1425 | | | | | Preferred? | 1426 | | | | ---------------- 1427 | | | | N | Y | 1428 | | | | | | 1429 Send Send Send Send Send Send 1430 C=0 C=1 C=0 C=0 C=0 C=1 1431 | | | | 1432 ---------------------------------- 1433 | If receive the same as sent, | 1434 | PW setup is complete. If not: | 1435 ---------------------------------- 1436 | | | | 1437 ------------------- ----------- 1438 | Receive | | Receive | 1439 | C=1 | | C=0 | 1440 ------------------- ----------- 1441 | | 1442 Wait for the Send 1443 next message Wrong C-Bit 1444 | 1445 Send Label 1446 Mapping Message