idnits 2.17.1 draft-ietf-pwe3-frame-relay-07.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 660. ** 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 an Introduction section. 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 (February 2006) is 6644 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) == Unused Reference: 'ITUG' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'FRAG' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'I233' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'FRF1' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'FRF2' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'FRF4' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'FRF10' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'FRF13' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'FRF14' is defined on line 728, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-16 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUG' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- No information found for draft-ietf-pwe3-hdlc-ppp-encap - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PPP' == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-08 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-fragmentation-08 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-atm-encap-05 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-06 Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini (Editor) 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: August 2006 Claude Kawa (Editor) 5 Andrew Malis (Editor) Oz Communications 6 Tellabs 8 February 2006 10 Encapsulation Methods for Transport of Frame Relay Over MPLS Networks 12 draft-ietf-pwe3-frame-relay-07.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 A frame relay pseudo wire is a mechanism that exists between a 39 provider's edge network nodes and support as faithfully as possible 40 frame relay services over MPLS packet switched network (PSN). This 41 document describes the detailed encapsulation necessary to transport 42 frame relay packets over an MPLS network. 44 Table of Contents 46 1 Specification of Requirements .......................... 3 47 2 Co-authors ............................................. 3 48 3 Acronyms and Abbreviations ............................. 4 49 4 Introduction ........................................... 4 50 5 Applicability Statement ................................ 6 51 6 General encapsulation method ........................... 6 52 7 Frame Relay over MPLS PSN for the One-to-One Mode ...... 7 53 7.1 MPLS PSN Tunnel and PW ................................. 7 54 7.2 Packet Format over MPLS PSN ............................ 8 55 7.3 The Control Word ....................................... 9 56 7.4 The Martini Legacy Mode Control Word ................... 10 57 7.5 PW packet processing ................................... 10 58 7.5.1 Encapsulation of Frame relay frames .................... 10 59 7.5.2 Setting the sequence number ............................ 11 60 7.6 Decapsulation of PW packets ............................ 11 61 7.6.1 Processing the sequence number ......................... 12 62 7.6.2 Processing of the Length Field by the Receiver ......... 12 63 7.7 MPLS Shim EXP Bit Values ............................... 13 64 7.8 MPLS Shim S Bit Value .................................. 13 65 7.9 Control Plane Details for Frame Relay Service .......... 13 66 7.9.1 Frame Relay Specific Interface Parameter sub-TLV ....... 13 67 8 Frame Relay Port Mode .................................. 14 68 9 Congestion Control ..................................... 14 69 10 IANA Considerations .................................... 15 70 11 Security Considerations ................................ 15 71 12 Full Copyright Statement ............................... 15 72 13 Intellectual Property Statement ........................ 16 73 14 Normative References ................................... 16 74 15 Informative References ................................. 17 75 16 Author Information ..................................... 18 76 17 Contributing Author Information ........................ 19 78 1. Specification of Requirements 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119. 84 Below are the definitions for the terms used throughout the document. 85 PWE3 definitions can be found in [PWE3REQ, RFC3985]. This section 86 defines terms specific to frame relay. 88 - Forward direction. 90 The forward direction is the direction taken by the frame being 91 forwarded. 93 - Backward direction. 95 In frame relay it is the direction opposite to the direction 96 taken by a frame being forwarded (see also forward direction). 98 2. Co-authors 100 The following are co-authors of this document: 102 Nasser El-Aawar Level 3 Communications, LLC 103 Eric C. Rosen Cisco Systems 104 Daniel Tappan Cisco Systems 105 Thomas K. Johnson Litchfield Communications 106 Kireeti Kompella Juniper Networks, Inc. 107 Steve Vogelsang Laurel Networks, Inc. 108 Vinai Sirkay Reliance Infocomm 109 Ravi Bhat Nokia 110 Nishit Vasavada Nokia 111 Giles Heron Tellabs 112 Dimitri Stratton Vlachos Mazu Networks,Inc. 113 Chris Liljenstolpe Cable & Wireless 114 Prayson Pate Overture Networks, Inc 116 3. Acronyms and Abbreviations 118 BECN Backward Explicit Congestion Notification 119 CE Customer Edge 120 C/R Command/Response 121 DE Discard Eligibility 122 DLCI Data Link Connection identifier 123 FCS Frame Check Sequence 124 FECN Forward Explicit Congestion Notification 125 FR Frame Relay 126 LSP Label Switched Path 127 LSR Label Switching Router 128 MPLS Multiprotocol Label Switching 129 MTU Maximum Transfer Unit 130 NNI Network-Network Interface 131 PE Provider Edge 132 PSN Packet Switched Network 133 PW Pseudo Wire 134 PWE3 Pseudo Wire Emulation Edge to Edge 135 POS Packet over SONET/SDH 136 PVC Permanent Virtual Circuit 137 QoS Quality of Service 138 SVC Switched Virtual Circuit 139 UNI User-Network Interface 140 VC Virtual Circuit 142 4. Introduction 144 In an MPLS or IP network, it is possible to use control protocols 145 such as those specified in [CONTROL] to set up "Pseudo Wires" that 146 carry the the Protocol Data Units of layer 2 protocols across the 147 network. A number of these emulated Pseudo Wires (PW) may be carried 148 in a single tunnel. The main functions required to support frame 149 relay PW by a PE include: 151 - Encapsulation of frame relay specific information in a suitable 152 pseudo wire (PW) packet, 153 - Transfer of a PW packet across an MPLS network for delivery to a 154 peer PE. 155 - Extraction of frame relay specific information from a PW packet 156 by the remote peer PE, 157 - Regeneration of native frame relay frames for forwarding across 158 an egress port of the remote peer PE, 159 - Execution of any other operations as required to support frame 160 relay service. 162 This document specifies the encapsulation for the emulated frame 163 relay VC over an MPLS PSN. Although different layer 2 protocols 164 require different information to be carried in this encapsulation, an 165 attempt has been made to make the encapsulation as common as possible 166 for all layer 2 protocols. Other layer 2 protocols are described in 167 separate documents. [ATM] [ETH] [PPP] 169 The following figure describes the reference models which are derived 170 from [RFC3985] to support the frame relay PW emulated services. 172 |<-------------- Emulated Service ---------------->| 173 | | 174 | |<------- Pseudo Wire ------>| | 175 | | | | 176 | | |<-- PSN Tunnel -->| | | 177 | PW End V V V V PW End | 178 V Service +----+ +----+ Service V 179 +-----+ | | PE1|==================| PE2| | +-----+ 180 | |----------|............PW1.............|----------| | 181 | CE1 | | | | | | | | CE2 | 182 | |----------|............PW2.............|----------| | 183 +-----+ ^ | | |==================| | | ^ +-----+ 184 ^ | +----+ +----+ | | ^ 185 | | Provider Edge 1 Provider Edge 2 | | 186 | | (PE1) (PE2) | | 187 Customer | | Customer 188 Edge 1 | | Edge 2 189 | | 190 | | 191 Attachment Circuit (AC) Attachment Circuit (AC) 192 native frame relay service native frame relay service 194 Figure 1: PWE3 frame relay PVC Interface Reference Configuration 196 Two mapping modes can be defined between frame relay VCs and pseudo 197 wires: The first one is called "one-to-one" mapping, because there 198 is a one-to-one correspondence between a frame relay VC and one 199 Pseudo Wire. The second mapping is called "many-to-one" mapping or 200 "port mode" because multiple frame relay VCs assigned to a port are 201 mapped to one pseudo wire. The "port mode" encapsulation is identical 202 to HDLC pseudo wire encapsulation which is described in [PPP]. 204 5. Applicability Statement 206 Frame Relay over PW service is not intended to perfectly emulate the 207 traditional frame relay service, but it can be used for applications 208 that need frame relay transport service. 210 The following are notable differences between traditional frame relay 211 service, and the protocol described in this document: 213 - Frame ordering can be preserved using the OPTIONAL sequence field 214 in the control word, however implementations are not required to 215 support this feature. 217 - The Quality of Service model for traditional frame relay can be 218 emulated , however this is outside the scope of this document. 220 - A Frame Relay Port mode PW, does not process any frame relay 221 status messages or alarms as described in [Q922] [Q933] 223 - The frame relay BECN, and FECN bit are transparent to the MPLS 224 network , and cannot reflect the status of the MPLS network. 226 - Support for frame relay SVC and SPVC is outside the scope of this 227 document. 229 - Frame relay LMI is terminated locally in the PE connected to the 230 frame relay attachment circuit. 232 - The support of PVC link integrity check is outside the scope of 233 this document. 235 6. General encapsulation method 237 The general frame relay pseudo wire packet format for carrying frame 238 relay information (user's payload and frame relay control 239 information) between two PEs is shown in Figure 2. 241 +-------------------------------+ 242 | | 243 | MPLS Transport header | 244 | (As required) | 245 +-------------------------------+ 246 | Pseudo Wire (PW) Header | 247 +-------------------------------+ 248 | Control Word | 249 +-------------------------------+ 250 | FR Service | 251 | Payload | 252 +-------------------------------+ 254 Figure 2 - General format of frame relay encapsulation over PSN 256 The PW packet consists of the following fields: Control word, and 257 Payload preceded by the MPLS Transport and pseudo wire header. The 258 meaning of the different fields is as follows: 260 -i. MPLS Transport header is specific to the MPLS network. This 261 header is used to switch the PW packet through the MPLS 262 core. 263 -ii. PW header contains an identifier for multiplexing PWs within 264 an MPLS tunnel. 265 -iii. Control Word contains protocol control information for 266 providing a frame relay service. Its structure is provided 267 in the following sections. 268 -iv. The contents of the frame relay service payload field 269 depends on the mapping mode. In general it contains the 270 layer 2 frame relay frame. 272 7. Frame Relay over MPLS PSN for the One-to-One Mode 274 7.1. MPLS PSN Tunnel and PW 276 MPLS label switched paths (LSPs) called "MPLS Tunnels" are used 277 between PEs and within the MPLS core network for forwarding purposes 278 of PW packets. An MPLS tunnel corresponds to "PSN Tunnel" of Figure 279 1. 281 Several "Pseudo Wires" may be nested inside one MPLS tunnel. Each PW 282 carries the traffic of a single frame relay VC. In this case the PW 283 header is an MPLS label called the PW label. 285 7.2. Packet Format over MPLS PSN 287 For the one-to-one mapping mode for frame relay over an MPLS network, 288 the PW packet format is shown in Figure 3. 290 +-------------------------------+ 291 | MPLS Tunnel label(s) | n*4 octets (four octets per label) 292 +-------------------------------+ 293 | PW label | 4 octets 294 +-------------------------------+ 295 | Control Word | 296 | (See Figure 4) | 4 octets 297 +-------------------------------+ 298 | Payload | 299 | (Frame relay frame | 300 | information field) | n octets 301 | | 302 +-------------------------------+ 304 Figure 3 - frame relay Over MPLS PSN Packet for the One-to-One 305 Mapping 307 The meaning of the different fields is as follows: 309 - MPLS Tunnel label(s) 311 The MPLS Tunnel label(s) corresponds to the MPLS transport header 312 of Figure 2. The label(s) is/are used by MPLS LSRs to forward a 313 PW packet from one PE to the other. 315 - PW Label 317 The PW label identifies one PW (i.e. one LSP) assigned to a frame 318 relay VC in one direction. It corresponds to the PW header of 319 Figure 2. Together the MPLS Tunnel label(s) and PW label form an 320 MPLS label stack [RFC3032]. 322 - Control Word 324 The Control Word contains protocol control information. Its 325 structure is shown in Figure 4. 327 - Payload 329 The payload field corresponds to X.36/X.76 frame relay frame 330 information field with bit/byte stuffing, frame relay header 331 removed, and FCS removed . It is RECOMMENDED to support a frame 332 size of at least 1600 bytes. The maximum length of the payload 333 field MUST be agreed upon by the two PEs. This can be achieved by 334 using the MTU interface parameter when the PW is established. 335 [CONTROL] 337 7.3. The Control Word 339 The control word defined below is REQUIRED for frame relay one-to-one 340 mode. The control word carries certain frame relay specific 341 information that is necessary to regenerate the frame relay frame on 342 the egress PE. Additionally, the control word also carries a 343 sequence number that can be used to preserve sequentiality when 344 carrying frame relay over an MPLS network. Its structure is as 345 follows: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |0 0 0 0|F|B|D|C|Res| Length | Sequence Number | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 4 - Control Word structure for the one-to-one mapping mode 355 The meaning of the Control Word fields (Figure 4) is as follows (see 356 also [X36 and X76] for frame relay bits): 358 - bits 0 to 3 360 In the above diagram the first 4 bits MUST be set to 0 to 361 indicate PW data. 363 - F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit. 365 - B (bit 5) FR BECN (Backward Explicit Congestion Notification) 366 bit. 368 - D (bit 6) FR DE bit (Discard Eligibility) bit. 370 - C (bit 7) FR frame C/R (Command/Response) bit. 372 - Res (bits 8 and 9): These bits are reserved and MUST be set to 373 0 upon transmission and ignored upon reception. 375 - Length (bits 10 to 15) 377 If the Pseudo Wire traverses a network link that requires a 378 minimum frame size (a notable example is Ethernet), padding is 379 required to reach its minimum frame size. If the frame's length 380 (defined as the length of the layer 2 payload plus the length of 381 the control word) is less than 64 octets, the length field MUST 382 be set to the PW payload length. Otherwise the length field MUST 383 be set to zero. The value of the length field, if non-zero, is 384 used to remove the padding characters by the egress PE. 386 - Sequence number (Bit 16 to 31) 388 Sequence numbers provide one possible mechanism to ensure the 389 ordered delivery of PW packets. The processing of the sequence 390 number field is OPTIONAL. The sequence number space is a 16 bit, 391 unsigned circular space. The sequence number value 0 is used to 392 indicate that the sequence number check algorithm is not used. 394 7.4. The Martini Legacy Mode Control Word 396 For backward compatibility to existing implementations the following 397 version of the control word is defined as the "martini mode CW" for 398 frame relay. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |0 0 0 0|B|F|D|C|Res| Length | Sequence Number | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 4 - Control Word structure for the frame relay martini mode 408 Note that the "B" and "F" bits are reversed. 410 This control word format is used for PW type "Frame Relay DLCI ( 411 Martini Mode )" 413 7.5. PW packet processing 415 7.5.1. Encapsulation of Frame relay frames 417 The encapsulation process of a frame relay frame is initiated when a 418 PE receives a frame relay frame from one of its frame relay UNI or 419 NNI interfaces. The PE generates the following fields of the control 420 word from the corresponding fields of the frame relay frame as 421 follows: 423 - Command/Response (C/R or C) bit: The C bit is copied unchanged in 424 the PW Control Word. 425 - The DE bit of the frame relay frame is copied into the D bit 426 field. However if the D bit is not already set, it MAY be set as 427 a result of ingress frame policing. If not already set by the 428 copy operation, setting of this bit by a PE is OPTIONAL. The PE 429 MUST NOT clear this bit (set it to 0 if it was received with the 430 value of 1). 431 - The FECN bit of the frame relay frame is copied into the F bit 432 field. However if the F bit is not already set, it MAY be set to 433 reflect a congestion situation detected by the PE. If not already 434 set by the copy operation, setting of this bit by a PE is 435 OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was 436 received with the value of 1). 437 - The BECN bit of the frame relay frame is copied into the B bit 438 field. However if the B bit is not already set, it MAY be set to 439 reflect a congestion situation detected by the PE. If not already 440 set by the copy operation, setting of this bit by a PE is 441 OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was 442 received with the value of 1). 443 - If the PW packet length (defined as the length of the payload 444 plus the length of the control word) is less than 64 octets, the 445 length field MUST be set to the packet's length. Otherwise the 446 length field MUST be set to zero. 447 - The sequence number field is processed if the PW uses sequence 448 numbers. [CW] 449 - The payload of the PW packet is the contents of ITU-T 450 Recommendations X.36/X.76 [X36] [X76] frame relay frame 451 information field stripped from any bit or byte stuffing. 453 7.5.2. Setting the sequence number 455 For a given PW, and a pair of routers PE1 and PE2, if PE1 supports 456 packet sequencing then the procedures in [CW] section 4.1 MUST be 457 followed. 459 7.6. Decapsulation of PW packets 461 When a PE receives a PW packet, it processes the different fields of 462 the control word in order to decapsulate the frame relay frame for 463 transmission to a CE on a frame relay UNI or NNI. The PE performs the 464 following actions (not necessarily in the order shown): 466 - It generates the following frame relay frame header fields from 467 the corresponding fields of the PW packet. 468 - The C/R bit MUST be copied in the frame relay header. 469 - The D bit MUST be copied into the frame relay header DE bit. 470 - The F bit MUST be copied into the frame relay header FECN bit. If 471 the F bit is set to zero, the FECN bit may be set to one, 472 depending on the congestion state of the PE device in the forward 473 direction. Changing the state of this bit by a PE is OPTIONAL. 474 - The B bit MUST be copied into the frame relay header BECN bit. If 475 the B bit is set to zero, the BECN bit may be set to one, 476 depending on the congestion state of the PE device in the 477 backward direction. Changing the state of this bit by a PE is 478 OPTIONAL. 479 - It processes the length and sequence field, the details of which 480 are in the following sub-sections. 481 - It copies the frame relay information field from the contents of 482 the PW packet payload after removing any padding. 484 Once the above fields of a FR frame have been processed, the standard 485 HDLC operations are performed on the frame relay frame: the HDLC 486 header is added, any bit or byte stuffing is added as required, and 487 the FCS is also appended to the frame. The FR frame is then queued 488 for transmission on the selected frame relay UNI or NNI interface. 490 7.6.1. Processing the sequence number 492 If a router PE2 supports receive sequence number processing, then the 493 procedures in [CW] section 4.2 MUST be used. 495 7.6.2. Processing of the Length Field by the Receiver 497 Any padding octet, if present, in the payload field of a PW packet 498 received MUST be removed before forwarding the data. 500 - If the Length field is set to zero then there are no padding 501 octets following the payload field. 502 - Else if the payload is longer then the length specified in the 503 control word padding characters are removed based on the length 504 field. 506 7.7. MPLS Shim EXP Bit Values 508 If it is desired to carry Quality of Service information, the Quality 509 of Service information SHOULD be represented in the EXP field of the 510 PW MPLS label. If more than one MPLS label is imposed by the ingress 511 LSR, the EXP field of any labels higher in the stack SHOULD also 512 carry the same value. 514 7.8. MPLS Shim S Bit Value 516 The ingress LSR, PE1, MUST set the S bit of the PW label to a value 517 of 1 to denote that the PW label is at the bottom of the stack. 519 7.9. Control Plane Details for Frame Relay Service 521 The PE MUST provide frame relay PVC status signaling to the frame 522 relay network. If the PE detects a service-affecting condition for a 523 particular DLCI, as defined in [Q933] Q.933 Annex A.5 sited in IA 524 FRF1.1, the PE MUST communicate to the remote PE the status of the PW 525 that corresponds to the frame relay DLCI status. The Egress PE SHOULD 526 generate the corresponding errors and alarms as defined in [Q922] 527 [Q933] on the egress Frame relay PVC. 529 There are two frame relay flags to control word bit mappings 530 described below. The legacy bit ordering scheme will be used for a PW 531 of type 0x0001 "Frame Relay DLCI (Martini Mode)", while the new bit 532 ordering scheme will be used for a PW of type 0x0019 "Frame Relay 533 DLCI". The IANA allocation registry of "Pseudowire Type" is defined 534 in [IANA] along with initial allocated values. 536 7.9.1. Frame Relay Specific Interface Parameter sub-TLV 538 A separate document [CONTROL], describes the PW control, and 539 maintenance protocol in detail including generic interface parameter 540 sub-TLVs. The interface parameter information, when applicable, MUST 541 be used to validate that the PEs, and the ingress and egress ports at 542 the edges of the circuit, have the necessary capabilities to 543 interoperate with each other. The Interface parameter TLV is defined 544 in [CONTROL], the IANA registry with initial values for interface 545 parameter sub-TLV types is defined in [IANA], but the frame relay 546 specific interface parameter sub-TLV types are specified as follows: 548 - 0x08 Frame Relay Header Length Sub-TLV. 550 An optional 16 bit value indicating the length of the FR Header 551 expressed in octets. This OPTIONAL interface parameter Sub-TLV 552 can have value of 2, 3, or 4, with the default being equal to 2. 553 If this Sub-TLV is not present the default value of 2 is assumed. 555 8. Frame Relay Port Mode 557 Frame relay port mode PW shares the same encapsulation as the HDLC 558 PW, and is described in the respective document. [PPP] 560 9. Congestion Control 562 As explained in [RFC3985], the PSN carrying the PW may be subject to 563 congestion, with congestion characteristics depending on PSN type, 564 network architecture, configuration, and loading. During congestion 565 the PSN may exhibit packet loss that will impact the service carried 566 by the frame relay PW. In addition, since frame relay PWs carry an 567 variety of services across the PSN, including but not restricted to 568 TCP/IP, they may or may not behave in a TCP-friendly manner 569 prescribed by [RFC2914]. In the presence of services that reduce 570 transmission rate, frame relay PWs may thus consume more than their 571 fair share and in that case SHOULD be halted. 573 Whenever possible, frame relay PWs should be run over traffic- 574 engineered PSNs providing bandwidth allocation and admission control 575 mechanisms. IntServ-enabled domains providing the Guaranteed Service 576 (GS) or DiffServ-enabled domains using EF (expedited forwarding) are 577 examples of traffic-engineered PSNs. Such PSNs will minimize loss and 578 delay while providing some degree of isolation of the frame relay 579 PW's effects from neighboring streams. 581 It should be noted that when transporting Frame Relay, DiffServ- 582 enabled domains may use AF (Assured Forwarding) and/or DF (Default 583 Forwarding) instead of EF, in order to place less burden on the 584 network and gain additional statistical multiplexing advantage. In 585 particular, if the CIR of a Frame Relay VC is zero, then it is 586 equivalent to a best-effort UDP over IP stream regarding congestion - 587 the network is free to drop frames as necessary. In this case, the 588 "DF" PHB would be appropriate in a diff-serv-TE domain. 589 Alternatively, if the CIR of a Frame Relay VC is nonzero and the DE 590 bit is zero in the FR header, then "AF31" would be appropriate to 591 use, and if the CIR of a Frame Relay VC is nonzero, but the DE bit is 592 on, then "AF32" would be appropriate [RFC3270]. 594 The PEs SHOULD monitor for congestion (by using explicit congestion 595 notification, [VCCV], or by measuring packet loss) in order to ensure 596 that the service using the frame relay PW may be maintained. When a 597 PE detects significant congestion while receiving the PW PDUs, the 598 BECN bits of the frame relay frame transmitted on the same PW SHOULD 599 be set to notify the remote PE, and the remote frame relay switch of 600 the congestion situation. In addition, the FECN bits SHOULD be set in 601 the FR frames sent out the attachment circuit, to give the FR DTE a 602 chance to adjust its transport layer advertised window if possible. 604 If the PW has been set up using the protocol defined in [CONTROL], 605 then procedures specified in [CONTROL] for status notification can be 606 used to disable packet transmission on the ingress PE from the egress 607 PE. The PW may be restarted by manual intervention, or by automatic 608 means after an appropriate waiting time. 610 10. IANA Considerations 612 This document has no IANA Actions. 614 11. Security Considerations 616 PWE3 provides no means of protecting the contents or delivery of the 617 PW packets on behalf of the native service. PWE3 may, however, 618 leverage security mechanisms provided by the MPLS Tunnel Layer. A 619 more detailed discussion of PW security is give in [RFC3985, CONTROL, 620 PWE3REQ]. 622 12. Full Copyright Statement 624 Copyright (C) The Internet Society (2006). 626 This document is subject to the rights, licenses and restrictions 627 contained in BCP 78, and except as set forth therein, the authors 628 retain all their rights. 630 This document and the information contained herein are provided on an 631 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 632 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 633 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 634 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 635 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 636 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 638 13. Intellectual Property Statement 640 The IETF takes no position regarding the validity or scope of any 641 Intellectual Property Rights or other rights that might be claimed to 642 pertain to the implementation or use of the technology described in 643 this document or the extent to which any license under such rights 644 might or might not be available; nor does it represent that it has 645 made any independent effort to identify any such rights. Information 646 on the procedures with respect to rights in RFC documents can be 647 found in BCP 78 and BCP 79. 649 Copies of IPR disclosures made to the IETF Secretariat and any 650 assurances of licenses to be made available, or the result of an 651 attempt made to obtain a general license or permission for the use of 652 such proprietary rights by implementers or users of this 653 specification can be obtained from the IETF on-line IPR repository at 654 http://www.ietf.org/ipr. 656 The IETF invites any interested party to bring to its attention any 657 copyrights, patents or patent applications, or other proprietary 658 rights that may cover technology that may be required to implement 659 this standard. Please address the information to the IETF at ietf- 660 ipr@ietf.org. 662 14. Normative References 664 [CONTROL] Luca Martini, et al., "Pseudowire Setup and Maintenance 665 using LDP", draft-ietf-pwe3-control-protocol-16.txt, 666 March 2005, work in progress. 668 [CW] "PWE3 Control Word for use over an MPLS PSN", S. Bryant, 669 G. Swallow, D. McPherson, draft-ietf-pwe3-cw-06.txt, ( work in 670 progress ), October 2005. 672 [ITUG] ITU Recommendation G.707, "Network Node Interface For The 673 Synchronous Digital Hierarchy", 1996. 675 [RFC3032] E. Rosen, et al., RFC 3032, MPLS Label Stack encoding, 676 January 2001. 678 [RFC3031] E. Rosen, et al., RFC 3031, MPLS Architecture, January 679 2001. 681 [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation 683 (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-09.txt 684 (work in progress), April 2004 686 [PPP] "Encapsulation Methods for Transport of PPP/HDLC Over MPLS 687 Networks", draft-ietf-pwe3-hdlc-ppp-encap-05.txt April 2005 689 15. Informative References 691 [RFC3985] Stewart Bryant, et al., PWE3 Architecture, 692 RFC3985 694 [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection 695 Verification (VCCV)", Internet Draft 696 draft-ietf-pwe3-vccv-08.txt, October 2005. (work in progress) 698 [FRAG] Andrew G. Malis, et al., PWE3 Fragmentation and 699 Reassembly, draft-ietf-pwe3-fragmentation-08.txt, 700 February 2005, ( work in progress ). 702 [ATM] "Encapsulation Methods for Transport of ATM Over MPLS 703 Networks", draft-ietf-pwe3-atm-encap-05.txt April 2005 704 (work in progress) 706 [ETH] "Encapsulation Methods for Transport of Ethernet Over 707 MPLS Networks", draft-ietf-pwe3-ethernet-encap-06.txt. 708 February 2005 (work in progress) 710 [I233] ITU-T Recommendation I.233.1, ISDN frame relay bearer 711 service, Geneva, October 1991. 713 [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, 714 Frame Relay Forum, April 2000. 716 [FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, 717 Frame Relay Forum, April 2002 719 [FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement, 720 Frame Relay Forum, January 2000. 722 [FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement, 723 Frame Relay Forum, January 2000. 725 [FRF13] FRF.13, Service Level Definition Implementation 726 Agreement, Frame Relay Forum, August 1998. 728 [FRF14] FRF.14, Physical layer Implementation Agreement, Frame 729 Relay Forum, December 1998. 731 [PWE3REQ] XiPeng Xiao, et al., RFC 3916. 733 [X36] ITU-T Recommendation X.36, Interface between a DTE and 734 DCE for public data networks providing frame relay, 735 Geneva, 2000. 737 [X76] ITU-T Recommendation X.76, Network-to-network interface 738 between public data networks providing frame relay 739 services, Geneva,2000. 741 [Q922] ITU-T Recommendation Q.922 Specification for Frame Mode 742 Basic call control, ITU Geneva 1995 744 [Q933] ITU-T Recommendation Q.933 Specification for Frame Mode 745 Basic call control, ITU Geneva 2003 747 [RFC2914] S Floyd, rfc2914, "Congestion Control Principles", 748 September 2000 750 [RFC3270] F. Le Faucheur, et al., rfc3270,"Multi-Protocol Label 751 Switching (MPLS) Support of Differentiated Services",May 2002 753 16. Author Information 755 Luca Martini 756 Cisco Systems, Inc. 757 9155 East Nichols Avenue, Suite 400 758 Englewood, CO, 80112 759 e-mail: lmartini@cisco.com 761 Claude Kawa 762 OZ Communications 763 Windsor Station 764 1100, de la Gauchetie`re St West 765 Montreal QC Canada 766 H3B 2S2 767 e-mail: claude.kawa@oz.com 769 Andrew G. Malis 770 Tellabs 771 90 Rio Robles Dr. 772 San Jose, CA 95134 773 e-mail: Andy.Malis@tellabs.com 775 17. Contributing Author Information 777 Kireeti Kompella 778 Juniper Networks 779 1194 N. Mathilda Ave 780 Sunnyvale, CA 94089 781 e-mail: kireeti@juniper.net 783 Giles Heron 784 Tellabs 785 Abbey Place 786 24-28 Easton Street 787 High Wycombe 788 Bucks 789 HP11 1NT 790 UK 791 e-mail: giles.heron@tellabs.com 793 Rao Cherukuri 794 Juniper Networks 795 1194 N. Mathilda Ave 796 Sunnyvale, CA 94089 798 Dimitri Stratton Vlachos 799 Mazu Networks, Inc. 800 125 Cambridgepark Drive 801 Cambridge, MA 02140 802 e-mail: d@mazunetworks.com 804 Chris Liljenstolpe 805 Cable & Wireless 806 11700 Plaza America Drive 807 Reston, VA 20190 808 e-mail: chris@cw.net 810 Nasser El-Aawar 811 Level 3 Communications, LLC. 812 1025 Eldorado Blvd. 813 Broomfield, CO, 80021 814 e-mail: nna@level3.net 815 Eric C. Rosen 816 Cisco Systems, Inc. 817 1414 Massachusetts Avenue 818 Boxborough, MA 01719 819 e-mail: erosen@cisco.com 821 Dan Tappan 822 Cisco Systems, Inc. 823 1414 Massachusetts Avenue 824 Boxborough, MA 01719 825 e-mail: tappan@cisco.com 827 Prayson Pate 828 Overture Networks, Inc. 829 507 Airport Boulevard 830 Morrisville, NC, USA 27560 831 e-mail: prayson.pate@overturenetworks.com 833 David Sinicrope 834 Ericsson IPI 835 e-mail: david.sinicrope@ericsson.com 837 Ravi Bhat 838 Nokia 839 e-mail: ravi.bhat@nokia.com 841 Nishit Vasavada 842 Nokia 843 e-mail: nishit.vasavada@nokia.com 845 Steve Vogelsang 846 Laurel Networks, Inc. 847 Omega Corporate Center 848 1300 Omega Drive 849 Pittsburgh, PA 15205 850 e-mail: sjv@laurelnetworks.com 851 Vinai Sirkay 852 Redback Networks 853 300 Holger Way, 854 San Jose, CA 95134 855 e-mail: sirkay@technologist.com