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