idnits 2.17.1 draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 557. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 184: '... preserved using the OPTIONAL sequence...' RFC 2119 keyword, line 273: '...he ECMP path, it MUST employ a mechani...' RFC 2119 keyword, line 292: '... implementations MUST be able to send ...' RFC 2119 keyword, line 295: '...es the egress PE MUST be aware of whet...' RFC 2119 keyword, line 313: '...DLC/PPP and they MUST be set to 0 when...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 2006) is 6556 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: 'Pn' is mentioned on line 406, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-16 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-frame-relay-06 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-fragmentation-08 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-08 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Eric C. Rosen 4 Expiration Date: November 2006 Cisco Systems, Inc. 6 Giles Heron 7 Andrew G. Malis 8 Tellabs 10 May 2006 12 Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks 14 draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 A Pseudowire (PW) can be used to carry Point to Point Protocol (PPP), 41 or High-Level Data Link Control (HDLC) Protocol Data Units over an 42 Multi Protocol Label Switching (MPLS) network without terminating the 43 PPP/HDLC protocol. This enables service providers to offer "emulated" 44 HDLC, or PPP link services over existing MPLS networks. This document 45 specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) 46 within a pseudo wire. 48 Table of Contents 50 1 Specification of Requirements .......................... 2 51 2 Introduction ........................................... 2 52 3 Applicability Statement ................................ 5 53 4 General encapsulation method ........................... 6 54 4.1 The Control Word ....................................... 6 55 4.2 MTU Requirements ....................................... 8 56 5 Protocol-Specific Details .............................. 9 57 5.1 HDLC ................................................... 9 58 5.2 Frame Relay Port Mode .................................. 9 59 5.3 PPP .................................................... 11 60 6 Using an MPLS Label as the Demultiplexer Field ......... 11 61 6.1 MPLS Shim EXP Bit Values ............................... 11 62 6.2 MPLS Shim S Bit Value .................................. 12 63 7 Congestion Control ..................................... 12 64 8 IANA Considerations .................................... 12 65 9 Security Considerations ................................ 13 66 10 Intellectual Property Statement ........................ 13 67 11 Full Copyright Statement ............................... 13 68 12 Normative References ................................... 14 69 13 Informative References ................................. 14 70 14 Author Information ..................................... 15 71 15 Contributing Author Information ........................ 16 73 1. Specification of Requirements 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 79 2. Introduction 81 A PPP/HDLC Pseudowire (PW) allows PPP/HDLC Protocol Data Units (PDUs) 82 to be carried over an MPLS network. In addressing the issues 83 associated with carrying a PPP/HDLC PDU over an MPLS network, this 84 document assumes that a Pseudowire (PW) has been set up by some means 85 outside the scope of this document. This may be via manual 86 configuration, or using the signaling protocol such as that defined 87 in [CONTROL]. 89 The following figure describes the reference models which are derived 90 from [ARCH] to support the HDLC/PPP PW emulated services. The reader 91 is also asummmed to be familiar with the content of the [ARCH] 92 Document. 94 |<-------------- Emulated Service ---------------->| 95 | | 96 | |<------- Pseudo Wire ------>| | 97 | | | | 98 | | |<-- PSN Tunnel -->| | | 99 | V V V V | 100 V AC +----+ +----+ AC V 101 +-----+ | | PE1|==================| PE2| | +-----+ 102 | |----------|............PW1.............|----------| | 103 | CE1 | | | | | | | | CE2 | 104 | |----------|............PW2.............|----------| | 105 +-----+ ^ | | |==================| | | ^ +-----+ 106 ^ | +----+ +----+ | | ^ 107 | | Provider Edge 1 Provider Edge 2 | | 108 | | | | 109 Customer | | Customer 110 Edge 1 | | Edge 2 111 | | 112 | | 113 native HDLC/PPP service native HDLC/PPP service 115 Figure 1: PWE3 HDLC/PPP Interface Reference Configuration 117 This document specifies the emulated PW encapsulation for PPP, and 118 HDLC, however quality of service related issues are not discussed in 119 this document. For the purpose of the discussion in this document PE1 120 will be defined as the ingress router, and PE2 as the egress router. 121 A layer 2 PDU will be received at PE1, encapsulated at PE1, 122 transported, decapsulated at PE2, and transmitted out on the 123 attachment circuit of PE2. 125 The following reference model describes the termination point of each 126 end of the PW within the PE: 128 +-----------------------------------+ 129 | PE | 130 +---+ +-+ +-----+ +------+ +------+ +-+ 131 | | |P| | | |PW ter| | PSN | |P| 132 | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN 133 | | |y| | | |on | | | |y| 134 | C | +-+ +-----+ +------+ +------+ +-+ 135 | E | | | 136 | | +-+ +-----+ +------+ +------+ +-+ 137 | | |P| | | |PW ter| | PSN | |P| 138 | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN 139 | | |y| | | |on | | | |y| 140 +---+ +-+ +-----+ +------+ +------+ +-+ 141 | | 142 +-----------------------------------+ 143 ^ ^ ^ 144 | | | 145 A B C 147 Figure 2: PW reference diagram 149 The PW terminates at a logical port within the PE, defined at point B 150 in the above diagram. This port provides an HDLC Native Service 151 Processing function that will deliver each PPP/HDLC packet that is 152 received at point A, unaltered, to the point A in the corresponding 153 PE at the other end of the PW. 155 The Native Service Processing (NSP) function includes packet 156 processing that is required for the PPP/HDLC packets that are 157 forwarded to the PW termination point. Such functions may include bit 158 stuffing, PW-PW bridging, L2 encapsulation, shaping, policing, etc. 159 These functions are specific to the native packet technology , and 160 may not be required for the PW emulation service. 162 The points to the left of B, including the physical layer between the 163 CE and PE, and any adaptation (NSP) functions between it and the PW 164 terminations, are outside of the scope of PWE3 and are not defined 165 here. 167 "PW Termination", between A and B, represents the operations for 168 setting up and maintaining the PW, and for encapsulating and 169 decapsulating the PPP/HDLC packets as necessary to transmit them 170 across the MPLS network. 172 3. Applicability Statement 174 PPP/HDLC transport over PW service is not intended to perfectly 175 emulate the traditional PPP or HDLC service, but it can be used for 176 some applications that require PPP or HDLC transport service. 178 The applicability statements in [FRAME] also apply to the Frame Relay 179 port mode PW described in this document. 181 The following are notable differences between traditional PPP/HDLC 182 service, and the protocol described in this document: 184 - Packet ordering can be preserved using the OPTIONAL sequence 185 field in the control word, however implementations are not 186 required to support this feature. 188 - The Quality of Service model for traditional PPP/HDLC links can 189 be emulated, however this is outside the scope of this document. 191 - A Frame Relay Port mode PW, or HDLC PW, does not process any 192 packet relay status messages or alarms as described in [Q922] 193 [Q933] 195 - The HDLC Flags are processed locally in the PE connected to the 196 attachment circuit. 198 The HDLC mode is suitable for port to port transport of Frame Relay 199 UNI or NNI traffic. Since all packets are passed in a largely 200 transparent manner over the HDLC PW, any protocol which has HDLC-like 201 framing may utilize the HDLC PW mode, including PPP, Frame-Relay, 202 X.25, etc. Exceptions include cases where direct access to the HDLC 203 interface is required, or modes which operate on the flags, Frame 204 Check Sequence (FCS) , or bit/byte unstuffing that is performed 205 before sending the HDLC PDU over the PW. An example of this is PPP 206 Asynchronous-Control-Character-Map (ACCM) negotiation. 208 For PPP since media-specific framing is not carried the following 209 options will not operate correctly if the PPP peers attempt to 210 negotiate them: 212 - Frame Check Sequence (FCS) Alternatives 213 - Address-and-Control-Field-Compression (ACFC) 214 - Asynchronous-Control-Character-Map (ACCM) 216 Note also that PW LSP Interface MTU negotiation as specified in 217 [CONTROL] is not affected by PPP MRU advertisement. Thus if a PPP 218 peer sends a PDU with a length in excess of that negotiated for the 219 PW tunnel that PDU will be discarded by the ingress router. 221 4. General encapsulation method 223 This section describes the general encapsulation format for PPP and 224 HDLC packets over MPLS pseudo wires. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | PSN Transport Header (As Required) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Pseudo Wire Header | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Control Word | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | PPP/HDLC Service Payload | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 3: General format for PPP/HDLC encapsulation over PSNs 240 The PSN Transport Header depends on the particular tunneling 241 technology in use. This header is used to transport the encapsulated 242 PPP/HDLC information through the packet switched core. 244 The Pseudo Wire Header identifies a particular PPP/HDLC service on a 245 tunnel. In case of MPLS the Pseudo Wire Header is the MPLS label at 246 the bottom of the MPLS label stack. 248 The Control Word is inserted before the PPP/HDLC service payload. It 249 may contain a length and sequence number. 251 4.1. The Control Word 253 There are four requirements that may need to be satisfied when 254 transporting layer 2 protocols over an MPLS PSN: 256 -i. Sequentiality may need to be preserved. 257 -ii. Small packets may need to be padded in order to be 258 transmitted on a medium where the minimum transport unit is 259 larger than the actual packet size. 260 -iii. Control bits carried in the header of the layer 2 packet may 261 need to be transported. 262 -iv. Creating an in-band associated channel for operation and 263 maintenance communications. 265 The Control Word defined in this section is based on the Generic PW 266 MPLS Control Word as defined in [CW]. It provides the ability to 267 sequence individual packets on the PW, avoidance of equal-cost 268 multiple-path load-balancing (ECMP) [RFC2992], and enables OAM 269 mechanisms including [VCCV]. 271 [CW] states, "If a PW is sensitive to packet mis-ordering and is 272 being carried over an MPLS PSN that uses the contents of the MPLS 273 payload to select the ECMP path, it MUST employ a mechanism which 274 prevents packet mis-ordering." This is necessary due to the fact that 275 ECMP implementations may examine the first nibble after the MPLS 276 label stack to determine whether the labeled packet is IP or not. 277 Thus, if the PPP protocol number of an PPP packet carried over the PW 278 without a control word present begins with 0x4 or 0x6, it could be 279 mistaken for an IPv4 or IPv6 packet. This could, depending on the 280 configuration and topology of the MPLS network, lead to a situation 281 where all packets for a given PW do not follow the same path. This 282 may increase out-of-order packets on a given PW, or cause OAM packets 283 to follow a different path than actual traffic. 285 The features that the control word provides may not be needed for a 286 given PPP/HDLC PW. For example, ECMP may not be present or active on 287 a given MPLS network, strict packet sequencing may not be required, 288 etc. If this is the case, the control word provides little value and 289 is therefore optional. Early PPP/HDLC PW implementations have been 290 deployed that do not include a control word or the ability to process 291 one if present. To aid in backwards compatibility, future 292 implementations MUST be able to send and receive packets without the 293 control word present. 295 In all cases the egress PE MUST be aware of whether the ingress PE 296 will send a control word over a specific PW. This may be achieved by 297 configuration of the PEs, or by signaling, as defined in [CONTROL]. 299 The control word is defined as follows: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |0 0 0 0|0 0 0 0|Res| Length | Sequence Number | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 4: MPLS PWE3 Control Word 309 In the above diagram the first 4 bits are set to 0 in indicate a CW 310 [CW]. 312 The next 4 bits provide space for carrying protocol specific flags. 313 These are not used for HDLC/PPP and they MUST be set to 0 when 314 transmitting, and MUST be ignored upon receipt. 316 The next 2 bits are reserved for future use, and MUST be set to 0 on 317 transmission and MUST be ignored on reception. 319 The next 6 bits provide a length field, which is used as follows: If 320 the packet's length (defined as the length of the layer 2 payload 321 plus the length of the control word) is less than 64 bytes, the 322 length field MUST be set to the packet's length. Otherwise the length 323 field MUST be set to zero. The value of the length field, if not 324 zero, is used to remove any padding that may have been added by the 325 MPLS network. If the control word is used, and padding was added to 326 the packet while transiting the MPLS network, then when the packet 327 reaches the egress PE the padding MUST be removed before forwarding 328 the packet. 330 The next 16 bits provide a sequence number that can be used to 331 guarantee ordered packet delivery. The processing of the sequence 332 number field is OPTIONAL.[CW] 334 The sequence number space is a 16 bit, unsigned circular space. The 335 sequence number value 0 is used to indicate an unsequenced 336 packet.[CW] 338 The procedures described in section 4 of [CW] MUST be followed to 339 process the sequence number field. 341 4.2. MTU Requirements 343 The network MUST be configured with an MTU that is sufficient to 344 transport the largest encapsulation packets. When MPLS is used as the 345 tunneling protocol, for example, this is likely to be 12 or more 346 bytes greater than the largest packet size. The methodology described 347 in [FRAG] MAY be used to fragment encapsulated packets that exceed 348 the PSN MTU. However if [FRAG] is not used then if the ingress router 349 determines that an encapsulated layer 2 PDU exceeds the MTU of the 350 PSN tunnel through which it must be sent, the PDU MUST be dropped. 352 If a packet is received on the attachment circuit that exceeds the 353 interface MTU subTLV value [CONTROL], it MUST be dropped. It is also 354 recommended that PPP devices MUST NOT negotiate PPP MRUs larger than 355 that of the AC MTU. 357 5. Protocol-Specific Details 359 5.1. HDLC 361 HDLC mode provides port to port transport of HDLC encapsulated 362 traffic. The HDLC PDU is transported in its entirety, including the 363 HDLC address, control and protocol fields, but excluding HDLC flags 364 and the FCS. Bit/Byte stuffing is undone. The control word is 365 OPTIONAL. If the control word is used then the flag bits in the 366 control word are not used, and MUST be set to 0 when transmitting, 367 and MUST be ignored upon receipt. 369 When the PE detects a status change in the attachment circuit status, 370 such as an attachment circuit physical link failure, or the AC is 371 administratively disabled, the PE MUST send the appropriate PW status 372 notification message that corresponds to the HDLC AC status. In a 373 similar manner, the local PW status MUST also be reflected in a 374 respective PW status notification message as described in [CONTROL]. 376 The PW of type 0x0006 "HDLC" will be used to transport HDLC packets. 377 The IANA allocation registry of "Pseudowire Type" is defined in the 378 IANA allocation document for PWs [BCP116] along with initial 379 allocated values. 381 5.2. Frame Relay Port Mode 383 Figure 5 illustrates the concept of frame relay port mode or many- 384 to-one mapping which is an OPTIONAL capability. 386 Figure 5a shows two frame relay devices physically connected with a 387 frame relay UNI or NNI. Between their two ports P1 and P2, n frame 388 relay VCs are configured. 390 Figure 5b shows the replacement of the physical frame relay interface 391 with a pair of PEs and a PW between them. The interface between a FR 392 device and a PE is either a FR UNI or NNI. The set of n FR VCs 393 between the two FR ports P1 and P2 which are controlled by the same 394 signaling channel using DLCI=0, are mapped into one PW. The standard 395 frame relay Link Management Interface (LMI) procedures happen 396 directly between the CEs. Hence with port mode we have many-to-one 397 mapping between FR VCs and a PW. 399 +------+ +-------+ 400 | FR | | FR | 401 |device| FR UNI/NNI | device| 402 | [P1]------------------------[P2] | 403 | | carrying n FR VCs | | 404 +------+ +-------+ 406 [Pn]: A port 408 Figure 5a: FR interface between two FR devices 410 |<---------------------------->| 411 | | 412 +----+ +----+ 413 +------+ | | One PW | | +------+ 414 | | | |==================| | | | 415 | FR | FR | PE1| carrying n FR VCs| PE2| FR | FR | 416 |device|----------| | | |---------|device| 417 | CE1 | UNI/NNI | | | | UNI/NNI | CE2 | 418 +------+ +----+ +----+ +------+ 419 | | 420 |<----------------------------------------------->| 421 n FR VCs 423 Figure 5b: Pseudo-wires replacing the FR interface 425 FR VCs are not visible individually to a PE; there is no 426 configuration of individual FR VC in a PE. A PE processes the set of 427 FR VCs assigned to a port as an aggregate. 429 FR port mode provides transport between two PEs of a complete FR 430 frame using the same encapsulation as described above for HDLC mode. 432 Although frame relay port mode shares the same encapsulation as HDLC 433 mode, a different PW type is allocated in [BCP116]: 0x000F Frame- 434 Relay Port mode. 436 All other aspects of this PW type are identical to the HDLC PW 437 encapsulation described above. 439 5.3. PPP 441 PPP mode provides point to point transport of PPP encapsulated 442 traffic, as specified in [PPP]. The PPP PDU is transported in its 443 entirety, including the protocol field (whether compressed using 444 Protocol Field Compression or not), but excluding any media-specific 445 framing information, such as HDLC address and control fields or FCS. 447 If the OPTIONAL control word is used then the flag bits in the 448 control word are not used, and MUST be set to 0 when transmitting, 449 and MUST be ignored upon receipt. 451 When the PE detects a status change in the attachment circuit (AC) 452 status, such as an attachment circuit physical link failure, or the 453 AC is administratively disabled, the PE MUST send the appropriate PW 454 status notification message that corresponds to the PPP AC status. It 455 should be noted that PPP negotiation status is transparent to the PW, 456 and MUST NOT be communicated to the remote MPLS PE. In a similar 457 manner, the local PW status MUST also be reflected in a respective PW 458 status notification message as described in [CONTROL]. 460 A PW of type 0x0007 "PPP" will be used to transport PPP packets. 462 The IANA allocation registry of "Pseudowire Type" is defined in the 463 IANA allocation document for PWs [BCP116] along with initial 464 allocated values. 466 6. Using an MPLS Label as the Demultiplexer Field 468 To use an MPLS label as the demultiplexer field, a 32-bit label stack 469 entry [MPLSENCAP] is simply prepended to the emulated PW 470 encapsulation, and hence will appear as the bottom label of an MPLS 471 label stack. This label may be called the "PW label". The particular 472 emulated PW identified by a particular label value must be agreed by 473 the ingress and egress LSRs, either by signaling (e.g, via the 474 methods of [CONTROL]) or by configuration. Other fields of the label 475 stack entry are set as described below. 477 6.1. MPLS Shim EXP Bit Values 479 If it is desired to carry Quality of Service information, the Quality 480 of Service information SHOULD be represented in the EXP field of the 481 PW label. If more than one MPLS label is imposed by the ingress LSR, 482 the EXP field of any labels higher in the stack MUST also carry the 483 same value. 485 6.2. MPLS Shim S Bit Value 487 The ingress LSR, PE1, MUST set the S bit of the PW label to a value 488 of 1 to denote that the PW label is at the bottom of the stack. 490 7. Congestion Control 492 As explained in [ARCH], the PSN carrying the PW may be subject to 493 congestion, with congestion characteristics depending on PSN type, 494 network architecture, configuration, and loading. During congestion 495 the PSN may exhibit packet loss that will impact the service carried 496 by the PPP/HLDC PW. In addition, since PPP/HDLC PWs carry an 497 unspecified type of services across the PSN, they cannot behave in a 498 TCP-friendly manner prescribed by [RFC2914]. In the presence of 499 services that reduce transmission rate, PPP/HDLC PWs will thus 500 consume more than their fair share and SHOULD be halted. 502 Whenever possible, PPP/HDLC PWs should be run over traffic-engineered 503 PSNs providing bandwidth allocation and admission control mechanisms. 504 IntServ-enabled domains providing the Guaranteed Service (GS) or 505 DiffServ-enabled domains using EF (expedited forwarding) are examples 506 of traffic-engineered PSNs. Such PSNs will minimize loss and delay 507 while providing some degree of isolation of the PPP/HDLC PW's effects 508 from neighboring streams. 510 The PEs SHOULD monitor for congestion (by using explicit congestion 511 notification, [VCCV], or by measuring packet loss) in order to ensure 512 that the service using the PPP/HDLC PW may be maintained. When 513 significant congestion is detected the PPP/HDLC PW SHOULD be 514 administratively disabled. If the PW has been set up using the 515 protocol defined in [CONTROL], then procedures specified in [CONTROL] 516 for status notification can be used to disable packet transmission on 517 the ingress PE from the egress PE. The PW may be restarted by manual 518 intervention, or by automatic means after an appropriate waiting 519 time. 521 8. IANA Considerations 523 This document has no new IANA Actions. All necessary IANA actions 524 have already been included in [BCP116]. 526 9. Security Considerations 528 The PPP and HDLC pseudowire type is subject to all of the general 529 security considerations discussed in [ARCH][CONTROL]. This document 530 specifies only encapsulations, and not the protocols that may be used 531 to carry the encapsulated packets across the MPLS network. Each such 532 protocol may have its own set of security issues, but those issues 533 are not affected by the encapsulations specified herein. 535 10. Intellectual Property Statement 537 The IETF takes no position regarding the validity or scope of any 538 Intellectual Property Rights or other rights that might be claimed to 539 pertain to the implementation or use of the technology described in 540 this document or the extent to which any license under such rights 541 might or might not be available; nor does it represent that it has 542 made any independent effort to identify any such rights. Information 543 on the procedures with respect to rights in RFC documents can be 544 found in BCP 78 and BCP 79. 546 Copies of IPR disclosures made to the IETF Secretariat and any 547 assurances of licenses to be made available, or the result of an 548 attempt made to obtain a general license or permission for the use of 549 such proprietary rights by implementers or users of this 550 specification can be obtained from the IETF on-line IPR repository at 551 http://www.ietf.org/ipr. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights that may cover technology that may be required to implement 556 this standard. Please address the information to the IETF at ietf- 557 ipr@ietf.org. 559 11. Full Copyright Statement 561 Copyright (C) The Internet Society (2006). 563 This document is subject to the rights, licenses and restrictions 564 contained in BCP 78, and except as set forth therein, the authors 565 retain all their rights. 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 570 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 571 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 572 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 12. Normative References 577 [CONTROL] "Pseudowire Setup and Maintenance using LDP", 578 Martini, L., et al., draft-ietf-pwe3-control-protocol-16.txt, 579 ( work in progress ), April 2005 581 [MPLSENCAP] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, 582 D. Tappan, G. Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 584 [BCP116] Martini L., "IANA Allocations for pseudo Wire Edge to Edge 585 Emulation (PWE3)", RFC4446, BCP116, April 2006 587 [CW] "PWE3 Control Word for use over an MPLS PSN", S. Bryant, 588 G. Swallow, D. McPherson, draft-ietf-pwe3-cw-06.txt, ( work in 589 progress ), October 2005. 591 [PPP] "The Point-to-Point Protocol (PPP)", RFC 1661. 593 [FRAME] "Frame Relay over Pseudo-Wires", 594 draft-ietf-pwe3-frame-relay-06.txt. December 2005, 595 (work in progress ) 597 13. Informative References 599 [ARCH] "PWE3 Architecture" Bryant, et al.,RFC3985 601 [FRAG] "PWE3 Fragmentation and Reassembly", A. Malis,W. M. Townsley, 602 draft-ietf-pwe3-fragmentation-08.txt ( work in progress ) 603 February 2005 605 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 606 Verification (VCCV)", Internet Draft 607 draft-ietf-pwe3-vccv-08.txt, October 2005. (work in progress) 609 [RFC2992] RFC-2992: Analysis of an Equal-Cost Multi-Path 610 Algorithm, C. Hopps, November 2000 612 [RFC2914] S. Floyd, "Congestion Control Principles" RFC 2914 614 [Q922] ITU-T Recommendation Q.922 Specification for Frame Mode 615 Basic call control, ITU Geneva 1995 617 [Q933] ITU-T Recommendation Q.933 Specification for Frame Mode 618 Basic call control, ITU Geneva 2003 620 14. Author Information 622 Luca Martini 623 Cisco Systems, Inc. 624 9155 East Nichols Avenue, Suite 400 625 Englewood, CO, 80112 626 e-mail: lmartini@cisco.com 628 Giles Heron 629 Tellabs 630 Abbey Place 631 24-28 Easton Street 632 High Wycombe 633 Bucks 634 HP11 1NT 635 UK 636 e-mail: giles.heron@tellabs.com 638 Eric C. Rosen 639 Cisco Systems, Inc. 640 1414 Massachusetts Avenue 641 Boxborough, MA 01719 642 E-mail: erosen@cisco.com 644 Andrew G. Malis 645 Tellabs 646 90 Rio Robles Dr. 647 San Jose, CA 95134 648 e-mail: Andy.Malis@tellabs.com 650 15. Contributing Author Information 652 Yeongil Seo 653 463-1 KT Technology Lab 654 Jeonmin-dong Yusung-gu 655 Daegeon, Korea 656 email: syi1@kt.co.kr 658 Toby Smith 659 Laurel Networks, Inc. 660 Omega Corporate Center 661 1300 Omega Drive 662 Pittsburgh, PA 15205 663 e-mail: tob@laurelnetworks.com