idnits 2.17.00 (12 Aug 2021) /tmp/idnits4483/draft-kamapabhava-fr-pwe3-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 74 has weird spacing: '...frame relay P...' == Line 854 has weird spacing: '...between a pai...' -- 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 (September 2001) is 7553 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: 'I233' is defined on line 1027, but no explicit reference was found in the text == Unused Reference: 'FRF1' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'FRF2' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'FRF4' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'FRF10' is defined on line 1039, but no explicit reference was found in the text == Unused Reference: 'PWE3REQ' is defined on line 1042, but no explicit reference was found in the text == Unused Reference: 'PWE3FW' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'RFC2615' is defined on line 1061, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'I233' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF4' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF10' == Outdated reference: draft-ietf-pwe3-requirements has been published as RFC 3916 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. 'PWE3REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'PWE3FW' -- Possible downref: Non-RFC (?) normative reference: ref. 'Q922' -- Possible downref: Non-RFC (?) normative reference: ref. 'Q933' -- Possible downref: Non-RFC (?) normative reference: ref. 'X36' -- Possible downref: Non-RFC (?) normative reference: ref. 'X76' Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PWE3 Working Group Claude Kawa 2 Internet Draft Nortel Networks 3 Expires: March 2002 Andrew G. Malis 4 Vivace Networks, Inc. 5 Prayson Pate 6 Overture Networks, Inc. 7 Ravi Bhat 8 Nishit Vasavada 9 Amber Networks 11 September 2001 13 Frame relay over Pseudo-Wire Emulation Edge-to-Edge 14 draft-kamapabhava-fr-pwe3-00.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance 19 with all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 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 material 28 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/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright(C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This document defines frame relay pseudo-wire (PW) specific aspects. A 42 frame relay PW allows frame relay protocol control information and 43 payload to be carried over Packet Switched Networks (PSNs) using IP, 44 L2TP, GRE or MPLS for transport. 46 Table of Contents 48 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 4 51 4. Requirements for Frame Relay Over PWE3 . . . . . . . . . . . . 4 52 5. Reference model . . . . . . . . . . . . . . . . . . . . . . . 5 53 6. General Encapsulation . . . . . . . . . . . . . . . . . . . . 5 54 7. PVC maintenance protocol. . . . . . . . . . . . . . . . . . . 10 55 8. Configuration prerequisites . . . . . . . . . . . . . . . . . 17 56 9. Frame Relay over MPLS. . . . . . . . . . . . . . . . . . . . . 18 57 10. Frame Relay over IP . . . . . . . . . . . . . . . . . . . . 19 58 11. Frame Relay over GRE. . . . . . . . . . . . . . . . . . . . 20 59 12. Frame Relay over L2TP. . . . . . . . . . . . . . . . . . . . 21 60 13. Security Considerations. . . . . . . . . . . . . . . . . . . 21 61 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 62 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 63 16.Author's Addresses . . . . . . . . . . . . . . . . . . . . . 22 65 Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119. 71 1. Introduction 73 This document defines frame relay pseudo-wire (PW) specific aspects. A 74 frame relay PW allows frame relay protocol control information and 75 payload to be carried over Packet Switched Networks (PSNs) using IP, 76 L2TP, GRE or MPLS for transport. A frame relay-pseudo wire is a 77 mechanism that emulates the essential attributes of frame relay service 78 over a PSN. The required functions of frame relay PWs include 80 - Encapsulating frame relay specific information receives at an ingress 81 port of a Provider Edge (PE) device, 83 - Carrying them across a PSN for delivery to another PE device, 85 - Extracting or decapsulating frame relay specific information, 87 - Generating of native frame relay frames for forwarding through an 88 egress port and, 90 - Performing any other operations required to support frame relay 91 service. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119. Below are the 98 definitions for the terms used throughout the document. 100 Packet Switched Network: 101 A Packet Switched Network (PSN) is a network 102 using IP, MPLS or L2TP as the unit of 103 switching. 105 Pseudo Wire Emulation Edge to Edge: 106 Pseudo Wire Emulation Edge to Edge (PWE3) is a 107 mechanism that emulates the essential 108 attributes of a service (such as a T1 leased 109 line or Frame Relay) over a PSN. 111 Customer Edge: A Customer Edge (CE) is a device where one end 112 of an emulated service originates and 113 terminates. The CE is not aware that it is 114 using an emulated service rather than a "real" 115 service. 117 Provider Edge: A Provider Edge (PE) is a device that provides 118 PWE3 to a CE. 120 Pseudo Wire: A Pseudo Wire (PW) is a connection between two 121 PEs carried over a PSN. The PE provides the 122 adaptation between the CE and the PW. 124 PW End Service: A Pseudo Wire End Service (PWES) is the 125 interface between a PE and a CE. This can be a 126 physical interface like a T1 or Ethernet, or a 127 virtual interface like a VC or VLAN. 129 Pseudo Wire PDU: A Pseudo Wire PDU is a PDU sent on the PW that 130 contains all of the data and control 131 information necessary to provide the desired 132 service. 134 PSN Tunnel: A PSN Tunnel is a tunnel inside which multiple 135 PWs can be nested so that they are transparent 136 to core network devices. 138 3. Acronyms and Abbreviations 140 CE Customer Edge 141 FR Frame relay 142 FRoPW Frame Relay over Pseudo Wire 143 LSP Label switched path 144 LSR Label switching router 145 MPLS Multi-protocol label switching 146 MTU Maximum Transfer Unit 147 NNI Network-Network Interface 148 PE Provider Edge 149 PSN Packet Switched Network 150 PW Pseudo-wire 151 POS Packet over Sonet/SDH 152 PVC Permanent virtual circuit 153 SPVC Switched/Soft permanent virtual circuit 154 SVC Switched virtual circuit 155 UNI User-Network Interface 156 VC Virtual circuit 158 4. Requirements for Frame Relay Over Pseudo-Wire Emulation Edge to edge 160 The section lists the main frame relay pseudo-wires requirements to be 161 met between two PEs: 163 1. Frame Transport: It must be possible to carry between two PEs both 164 user and maintenance PSN traffic on the same pseudo-wire. It should be 165 possible also to distinguish between the two types of traffic. 167 2. Frame Length: Must transport variable length frame relay frames 168 without being limited by the PSN MTU. 170 3. Bi-directional traffic: Must support bi-directional traffic. 172 4. Frame ordering: Must preserve frame relay frames order. 174 5. Control bits: Must support the transport of frame Discard Eligibility 175 (DE), Forward Explicit Congestion Notification (FECN), Backward Explicit 176 Congestion Notification (BECN) and Command/Response (C/R) bits [Q922] 178 6. PVC Status Maintenance: Must support the mapping and transport of 179 frame relay PVC status indications defined in Q933 Annex A [Q933]. The 180 support of PVC continuity check should be provided. 182 7. Traffic Management: Should be able to map the following frame relay 183 traffic management parameters to PWs traffic parameters: 185 a) CIR (Committed Information Rate) or throughput, 186 b) Bc (Committed burst size), 187 c) Be (Excess Burst Size), 188 e) Maximum frame size. 190 8. Frame Priority and QoS: Should support the ability to map different 191 frame relay priorities or QoS classes as defined in [X36, X76] [X36, 192 X76] to appropriately engineered PWs and tunnel PSNs. 194 9. Frame relay VC type: Must support PVC, support of SVC and SPVC is 195 optional. 197 5. Reference model 199 Figure 1 shows PWE3 reference model with additional frame relay 200 concepts. This section will be completed with additional details 201 imported from [PWE3REQ and PWE3FW]. 203 (To be completed) 205 |<------- Pseudo Wire ------>| 206 | | 207 | |<-- PSN Tunnel -->| | 208 PW V V V V PW 209 End Service +----+ +----+ End Service 210 (FR UNI or NNI)| | | | (FR UNI or NNI) 211 +-----+ | | PE1|==================| PE2| | +-----+ 212 | |----------|............PW1.............|----------| | 213 | CE1 | | | | | | | | CE2 | 214 | |----------|............PW2.............|----------| | 215 +-----+ | | |==================| | | +-----+ 216 ^ +----+ +----+ | ^ 217 | Provider Edge 1 Provider Edge 2 | 218 | | 219 |<------------- Emulated Service ----------------->| 220 (i.e. FR PVC, SVC or SPVC) 221 Customer Customer 222 Edge 1 Edge 2 224 Figure 1 - PWE3 Reference Model 226 6. General Encapsulation and FRoPW packet processing 228 6.1. General Encapsulation 230 The general packet format to transmit frame relay information (user's 231 payload and frame relay control information) from one PE to another is 232 shown in Figure 2. 234 +-------------------------------+ 235 | | 236 | Delivery Header | 237 | | 238 +-------------------------------+ 239 | | 240 | FRoPW Header | 241 | | 242 +-------------------------------+ 243 | | 244 | Payload packet | 245 | | 246 +-------------------------------+ 248 Figure 2 - General format of FRoPW packet 250 The delivery header is a header specific to the PSN, it is discussed in 251 the following sections addressing each type of PSN. FRoPW header 252 contains protocol control information, its structure is shown in Figure 253 3. The packet payload field is the content of the information field of 254 frame relay frame defined in ITU-T Recommendation Q.922 Annex A [Q922]. 256 FRoPW header structure is shown in Figure 3. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Res |P|F|B|D|C|X|Y| Length | Sequence Number | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 3 - FRoPW header structure 266 The meaning of the fields is as follows: 267 Res (bits 0 to 2): 268 Reserved bits. They are set to zero on transmission and ignored on 269 reception. 271 P - Payload Type (bit 3): 272 If set to zero then the payload field contains user's data else it 273 contains network maintenance data. 275 F - FECN (bit 4): 276 FR FECN (Forward Explicit Congestion Notification) bit [Q922]. 278 B - BECN (bit 5): 279 FR BECN (Backward Explicit Congestion Notification) bit [Q.922]. 281 D - DE (bit 6) 282 FR DE bit indicates the discard eligibility [Q922]. 284 C/R (bit 7) 285 FR frame C/R (command/response) bit [Q922]. 287 X, Y (bits 8 and 9): 288 1 0: First segment of a segmented FRoPW packet 289 0 1: Last segment of a segmented FRoPW packet 290 0 0: Neither the first nor the last segment of a segmented FRoPW packet 291 1 1: Complete FRoPW packet 293 X and Y bits are used for segmentation and re-assembly of FroPW packet 294 fragments when these capabilities are enabled in the two PEs terminating 295 a PW. 297 Length (bits 10 to 15): 298 The length field is used to pad short FRoPW packets over Ethernet PSN. 299 The length field is used as follows: If the length of the layer 2 frame 300 (consisting of layer two control information and layer 2 payload) is 301 less than 64 bytes, the length field MUST be set to the FRoPW packet 302 length. Otherwise the length field MUST be set to zero. The value of the 303 length field, if non-zero, is used to remove any padding. 305 Sequence number (Bit 16 to 31): 306 If not used it is set to zero by the sender and ignored by the receiver. 307 Otherwise it specifies the sequence number of a complete FRoPW packet or 308 a fragment. A circular list of sequence numbers is used. A sequence 309 number takes a value from 1 to 65535 (2**16-1). Arithmetic modulo 2**16 310 is used to generate a new sequence number. 312 The sequence number must be used when segmentation and re-assembly are 313 enabled between two peer PEs terminating a PSN tunnel. The sequence 314 number may be used to detect out-of-order delivery of FRoPW packets when 315 the PSN does not guarantee in-order delivery. 317 6.2. FRoPW packet processing 319 (Section and subsections to be completed) 321 6.2.1. Generating FRoPW packets 323 The generation process of a FRoPW packet is initiated when a PE receives 324 a frame relay frame from one of its frame relay UNI or NNI. The PE takes 325 the following actions (not necessarily in the order shown): 327 - It generates the following fields of FRoPW header from the 328 corresponding fields of the frame relay frame: C/R, DE, FECN and BECN, 330 - The length field will be addressed in the next iteration of this 331 draft. 333 - The sequence field is set according to the configuration parameters. 334 Details are provided below. 336 - The payload field is the contents of the frame relay information field 337 stripped from any escape bit or character. 339 Once the FRoPW packet has been generated, additional processing specific 340 to the type of PW used and the underlying PSN is performed. 342 6.2.1.1. Setting the sequence number 344 If the two PEs terminating a PSN tunnel support packet sequencing 345 capability then the following procedure to number FRoPW packets is used: 347 - The initial packet transmitted on the frame relay PW MUST use 348 sequence number 1, 350 - For a subsequent packet, the sequence number corresponds to the 351 sequence number of the preceding packet incremented by 1 modulo 2**16, 353 - when the sequence number reaches the maximum 16 bit 354 value (65535) the next sequence number wrap to 1. 356 If the PEs do not support sequence number processing, then the sequence 357 number field MUST be set to 0. 359 6.2.1.2. Sequence number and segmentation of long FRoPW packets 360 (To be completed) 362 6.2.2. Receiving FRoPW packets 364 (Section and subsections to be completed) 366 When a PE receives a FRoPW packet, it processes the different FRoPW 367 header fields in order to synthesize a new frame relay frame for 368 transmission through one of its frame relay UNI or NNI. The PE performs 369 the following actions(not necessarily in the order shown): 371 Note - PSN and PW specific processing are specified in the section on 372 each type of PSN. 374 - The PE checks the P bit to ensure that it is set to "user's data", 376 - It generates the following frame relay frame fields from the FRoPW 377 header: C/R, DE, FECN and BECN, 379 - It processes the length and sequence field, 381 - It generates the frame relay information field from the contents of 382 the FRoPW packet payload. 384 Once the frame relay frame has been generated, it is queued for 385 transmission across the selected frame relay UNI or NNI. 387 6.2.2.1 Checking the sequence number 389 If the receiving PE support packet sequencing, the processing is done as 390 follows: 392 The "expected sequence number" of the first FRoPW packet is 1. 394 When a packet is received the sequence number is processed as follows: 396 - If the sequence number of the packet is 0, then the packet passes the 397 sequence number check 399 - Otherwise if the packet sequence number >= the expected sequence 400 number and the packet sequence number - the expected sequence 401 number < 32768, then the packet is in order. 403 - Otherwise if the packet sequence number < the expected sequence 404 number and the expected sequence number - the packet sequence 405 number >= 32768, then the packet is in order. 407 - Otherwise the packet is out of order. 409 If a packet passes the sequence number check, it is kept for further 410 processing in order to be forwarded to its next destination. 412 If the packet is in order, then the expected sequence number should be 413 set using the following assignment: 415 expected_sequence_number := packet_sequence_number + 1 mod 2**16 416 if (expected_sequence_number = 0) then expected_sequence_number := 1; 418 Packets, which are received out of order, MAY be dropped or reordered at 419 the discretion of the receiver. 421 If the receiving PE does not support sequence number processing, then 422 the sequence number field MAY be ignored. 424 6.2.2.2 Sequence number and segmentation of long FRoPW packets 426 (To be completed) 428 6.3. Segmentation and Re-assembly procedures 430 (Section and subsections to be completed) 432 6.3.1. Segmentation procedure 433 Segmentation is performed when the information field of the frame relay 434 frame received is too long for transmission across the PSN and when the 435 configuration of the PSN tunnel and/or PW allows segmentation to be 436 performed. X and Y bits are used to indicate the type of segment: First 437 segment (X bit set to 1), last segment (Y bit set to 1) neither the 438 first not the last segment (X and Y bits set to 0). The sequence number 439 is used to number the fragments. If packet sequencing is used for every 440 packet, numbering FRoPW packet fragments follows the same procedure as 441 numbering complete packets: For every packet fragment, the sequence 442 number is the sequence number of the previous packet/fragment 443 incremented by one modulo 2**16. When packet sequencing is not used for 444 every packet but only with segmentation and re-assembly, the sequence 445 number of is re-initialized for every long packet that requires 446 segmentation. The first FRoPW packet fragment has sequence number and 447 for each subsequent fragment, the sequence number is incremented by 1 448 modulo 2**16. 450 If segmentation is not allowed and the frame relay frame is too long for 451 transmission in a single FRoPW packet, it shall be discarded. 453 (Detailed procedures will be provided in the next version of this draft} 455 6.3.2. Re-assembly procedure 456 When a frame relay frame has been segmented by the sending PE and 457 segmentation/re-assembly is allowed by the receiving PE, the receiving 458 PE will re-assemble the frame relay segments received in FRoPW packets 459 to regenerate the original frame relay information field. 461 (Detailed procedures will be provided in the next version of this draft} 463 6.4. Handling of error conditions 465 To be completed. 467 6.5. FR SVC and SPVC Signalling between PEs 469 To be completed 471 6.6. FR PVC provisioning 473 Provisioning of frame relay VCs requires the following actions: Frame 474 relay VC segments (see Figure 1) are provisioned between each CE and the 475 corresponding PE. A FR PW is established between the two PEs to 476 complete the Frame Relay VC. 478 The two PEs terminating a frame relay PW executed a PVC maintenance 479 protocol to exchange PVC status information and for "keep-alive" 480 purposes. The PVC maintenance protocol is defined in the following 481 section. 483 7. PVC maintenance protocol 485 This section specifies how the status of a PVC is reported between two 486 PEs when a PVC is created, deleted or when it changes state and how and 487 when the keep alive function is performed. 489 7.1. PVC maintenance message format 491 PEs use a PVC maintenance protocol to exchange PVC status and keep-alive 492 information. The message format of the PVC maintenance protocol is shown 493 in Figure 4 and the explanation of the different fields follows. A PVC 494 maintenance message is encapsulated in the payload field of FR-MPLS/PW 495 packet with the P bit set to "network data". 497 A PE sends a PVC maintenance protocol message in its transmitting PSN 498 tunnel. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | V=0001| Message type |State | MSN | Reserved | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 4 - PVC maintenance message format 508 Meaning of each field: 509 Bits 0 to 3: Version number (V) 510 The version number of the PVC maintenance protocol. 511 This version is version 0001. 513 Bits 4 to 11: Message type 514 This field identifies a PVC maintenance protocol message. The following 515 messages are defined: 516 0000 0000: PVC status indication 517 0000 0001: PVC status response 518 0000 0010: Keep alive indication 519 0000 0011: Keep alive response 520 Other values are reserved for future use. 522 Bits 12 to 15: PVC state 523 This field indicates the operational state of a PVC as follows: 525 A (active) bit 526 This bit indicates whether the PVC is active (value 1) or inactive 527 (value 0). 529 N (new) bit 530 This bit indicates whether the status reporting is for a new PVC (value 531 1) or an existing PVC (value 0). 533 D (delete) bit 534 This bit indicates that a PVC will be deleted when it is set to 1. D bit 535 set to 0 is used with other PVC status announcement. 537 Bits 16 to 23: Message correlation number (MSN) 538 This field allows the correlation of a PVC status indication message 539 with the corresponding PVC status response or a keep alive indication 540 message with the corresponding keep-alive response message. 542 Note on the use of the Message correlation number field: 543 The field value is an integer between 0 and 255. A simple way to 544 generate Message correlation numbers is to use a counter modulo 256 per 545 frame relay PW. Before transmitting a new PVC status /keep-alive 546 indication message, a PE inserts a new value of the counter in the Message 547 correlation number field. A receiving PE returns in a PVC status /keep-alive 548 response message the value of the message correlation number received in the 549 corresponding PVC status/keep-alive indication message. 551 Bits 24 to 31: Reserved 552 These bits are reserved for future use. 554 7.2. Execution of PVC maintenance protocol 556 PVC maintenance functions may be executed to report a PVC state change 557 or for keep-alive purposes in the absence of user's traffic. Each side 558 of a related pair of PSN tunnel has a timer T1 to indicate when PVC 559 maintenance protocol functions are executed. However, any time before T1 560 expires a PE may send a PVC status indication message to inform the 561 other side of a PVC state change in a timely manner. But keep-alive 562 functions are executed only when T1 expires. Note timer T1 applies to a 563 pair of bi-directional PSN tunnel and not to individual nested frame 564 relay PW. 566 7.3. Notification of a newly created PVC 568 A PE shall send a PVC status indication message to notify its peer that 569 a PVC has been created. The N bit is set to 1 (new PVC). If the PE is 570 ready to send and receive user's frames it shall set the A bit to 1 571 (active) otherwise it shall set it to 0. The PE shall insert a Message 572 correlation number as described in Section 7.1. The other fields are set 573 as shown in Figure 1 and decribed in Section 7.1. 575 If the PE does not receive a reply when timer T1 expires it shall 576 retransmit the PVC status message with the N bit set to 0 (new) and the 577 A bit set according to the availability of the PVC with a new Message 578 correlation number. At any time there is only one outstanding PVC status 579 indication message per frame relay PW. The PVC status message may be 580 retransmitted up to N1 time (the default value of N1 is 255 581 retransmissions) but only after T1 expires. After N1 retransmissions the 582 management system is notifies of the lack of reply and the PE may 583 continue with the retransmission of the PVC status indication message 584 until further notification by the management system. 586 When a PVC status response message is received, the PE receiving the PVC 587 status response message checks the various fields to ensure that they 588 are correct. In particular, the Message correlation number must 589 correspond to the Message correlation number of a the last transmitted 590 PVC status indication message awaiting a reply, otherwise the PVC status 591 reply message is silently discarded. 593 The receiver checks also the N bit and A bit. The N bit must be set to 1 594 (new PVC) otherwise the management system must be notified and the PVC 595 must be unavailable for use until further notification by the management 596 system. If the A bit is set to 0 (inactive) no user frames may be 597 transmitted or received. If the A bit is set to 1 (active) transmission 598 of user frame is allowed only if the PVC is active at this side too. 600 Transmission in the two directions is allowed only when the PVC is 601 active at the two ends of the VC LSPs. Any user's frame received when 602 the PVC is not active at the two PEs shall be discarded. 604 7.4. Replying to the notification of a newly created PVC 606 When a PE receives from its peer a PVC status indication message 607 indicating that a PVC has been created, it shall reply by returning a 608 PVC status response message as follows: 610 1. If the PVC has been created at this side, the N bit shall be set to 1 611 2. (new PVC). 613 3. If the A bit received in the PVC status indication message was set to 614 1 (active) and the PVC has been activated at this side, the A bit shall 615 be set to 1 otherwise it shall be set to zero (inactive). 617 7.5. Notification of PVC activation 619 A PE shall send a PVC status indication message to notify its peer that 620 a PVC is active at its side and ready to send and receive user's data. 621 The PE shall set the N bit to 0 (existing PVC) and the A bit to 1 622 (active). The other fields are set as explained in Section 7.1. 624 If the PE does not receive a reply when timer T1 expires it shall 625 retransmit the PVC status message with the N bit set to 0 and the A bit 626 set to according to the activation state of the PVC at this side. The 627 PVC status message may be retransmitted up to N1 time. After N1 628 retransmission the management system is notifies of the lack of a reply 629 and the PE may continue to retransmit the PVC status message to notify 630 the other side that the PVC is active until further notification by the 631 management system. 633 When a reply is received indicating that the PVC is active, user frames 634 may be sent in both directions. Otherwise, any user's frame received it 635 will be discarded. 637 7.6. Replying to the notification of PVC availability 639 When a PE receives from its peer a PVC status indication message 640 indicating that a PVC is available (active), it shall reply by returning 641 a PVC status response message as follows: 643 1. If the PVC has been created at this side and is active, the N bit 644 shall be set to 0 and the A bit to 1 (active) 646 2. If the PVC has been created and is not active it shall set the N bit 647 to 0 and the A bit to 0 (inactive). 649 If the identification of the frame relay PW does not correspond to a 650 configured PVC, the PVC status indication message received is discarded 651 and no reply is returned. 653 7.7. Notification of PVC de-activation 655 A PE shall send a PVC status indication message to notify its peer that 656 a PVC is inactive at its side. The PE shall set the N bit to 0 (existing 657 PVC) and the A bit to 0 (inactive). The other fields are described in 658 Section 7.1. 660 If the PE does not receive a reply when timer T1 expires it shall 661 consider the PVC inactive and any user's frame received shall be 662 discarded. The PVC status message is retransmitted up to N1 time. After 663 N1 retransmissions the management system is notified of a lack of a 664 reply. 666 If a user frame is received when a PVC is inactive, it shall be 667 discarded and the PE may retransmit the PVC status message to notify the 668 other side that the PVC is inactive 670 When a reply is received indicating that the PVC is inactive, user 671 frames must not be sent in any direction until the PVC has been 672 activated at the two sides. Any user's frame received when the PVC is 673 received will be discarded and the receiving side may return a PVC 674 status message indicating that the PVC is still inactive. 676 7.8. Replying to the notification of PVC de-activation 678 When a PE receives from its peer a PVC status indication message 679 indicating that a PVC is unavailable (inactive), if the PVC is 680 configured, it shall reply by returning a PVC status message with the N 681 bit set to 0 and the A bit to 0 (inactive). 683 If the identification of the frame relay PW does not correspond to a 684 configured PVC, the PVC status indication message received is discarded 685 and no reply is returned. 687 No user's frames may be sent when the PVC is inactive. Any user's frame 688 received is discarded. 690 7.9. PVC status checking 692 At the expiration of timer T1 a PE may send a PVC status indication 693 message to the other PE with the PVC state bits (D, N and A) set to 694 appropriate values to elicit a response from the other PE about the PVC 695 state. This procedure is useful, for example, when a PVC has been de 696 activated for too long and one of the PE wants to check the PVC state at 697 the other side. 699 7.10. Notification of the deletion of a PVC 701 When a PVC is in the process of being deleted, a PE notifies the other 702 side by sending a PVC status indication message with the D bit set to 1, 703 the N bit must be set to 0 (existing PVC) and the A bit to 0 (inactive). 704 One or both sides may initiate the PVC deletion notification procedure. 705 When both sides initiate the procedure, each side must reply to the PVC 706 status indication message sent by the other side. If no reply is 707 received, the PVC status indication message may be retransmitted up to 708 N3 times. After N3 retransmissions the management system is notified of 709 a lack of a reply and the PVC is considered deleted. 711 When the PE receives a PVC status response message replying to the 712 notification of the deletion of a PVC, it shall ensure that the Message 713 correlation number is valid and the D bit received is set to 1, 714 otherwise it shall discard the PVC status response message. If the 715 message received is correct and after performing any other book-keeping 716 function at this side, the PVC is considered deleted at this side. 718 7.11. Reply to the notification of the deletion of a PVC 720 When a PE receives from its peer a PVC status indication message 721 indicating that a PVC is in the process of being deleted, it shall 722 return a PVC status response message with the D bit set to 1, the N bit 723 set to 0 and the A bit to 0. The other fields are set according to 724 Figure 1 and Table 1. After sending the PVC status response message and 725 after performing any other book-keeping function, the PVC shall be 726 considered deleted at this side. 728 7.12. Keep-alive function 730 The keep-alive procedure is optional to implement, it is performed for 731 each frame relay PW in the absence of user's or PVC status reporting 732 traffic in one or both directions and does not induce a PVC state change 733 in a PE. It merely allows a PE to inform the other PE that it is 734 functioning. 736 The keep alive procedure is executed by the PEs when timer T1 expires. A 737 PE does not have to execute the keep-alive procedure every time timer T1 738 expires, in particular under heavy load or for any other reason. 740 7.12.1. Sending a keep alive request message 742 A PE may initiate the keep-alive procedure when one of the following 743 conditions is met: 745 1. There has not been any user's traffic in one or both directions and 746 the PVC is in the active state when timer T1 expires, 747 2. There is no PVC status reporting message to send to the other PE 748 applicable to the corresponding VC LSP, 750 3. For other implementation-specific reasons. 752 When one of the above conditions is met, a PE initiates the execution of 753 the keep-alive procedure by sending a keep-alive indication message to 754 the other PE indicating the PVC state at its side. The PVC state bits 755 are set according to the PVC state at the PE side. 757 When a keep-alive response message is received. The PVC state bits are 758 checked to determine if there is a state mismatch. When a state mismatch 759 exists, the PE receiving he keep-alive response message shall execute 760 the PVC status reporting procedures to bring the PVC to the same state 761 at the two PEs. The PVC state bits are set to the lowest common 762 denominator (detailed will be provided in the next version). 764 The PE shall take no special action if no reply to the keep-alive 765 indication message is received at or before the next expiration of timer 766 T1. However if there is no activity on the frame relay PWs in the 767 transmitting and receiving directions after N2 retransmissions of the 768 keep-alive indication message and no reply to the keep-alive indication 769 message has been received, the network management system shall be 770 informed. The PE may continue executing the PVC maintenance protocol 771 until it receives a notification from the management system. 773 7.12.2. Replying to a keep alive indication message 775 When a PE receives a keep-alive indication message it returns a keep- 776 alive response indicating the state of the PVC at its side, if the PVC 777 state at its side is consistent with the PVC state received in the keep- 778 alive indication message. If the PVC state is inconsistent the PE shall 779 execute the PVC status reporting procedure without returning the keep- 780 alive response message in order to bring the PVC in the same state at 781 the two sides. The PVC state bits are set to the lowest common 782 denominator (details will be provided in the next version). 784 7.13. Resumption of PVC activities after a failure 786 After a failure (link layer, transmission facility or internal failure) 787 a PE shall execute the PVC status activation to return the PVC to the 788 active state between the two PEs. 790 7.14. Handling of error conditions 792 As a general rule, if a PVC receives a PVC maintenance message with 793 erroneous information, it shall discard it. In particular: 795 1. If a PE receives an unexpected PVC maintenance message, 797 2. If a PE received a PVC maintenance message with a content not as 798 specified in Section 7.1, 799 3. If a PE receives a PVC maintenance message with the N bit set to 0 800 (existing PVC) and a frame relay PW identification not recognized as 801 belonging to a configured PVC, 803 4. If a PE receives a PVC maintenance status response message with an 804 invalid Message correlation number. 806 7.15. PVC maintenance protocol Parameters 808 Timers: 809 Timer T1 - This timer exists at each peer PE for a pair of bi- 810 directional. tunnel LSP. It controls the periodical execution of the PVC 811 maintenance protocol. 812 The default value of timer T1 is 1 second. 814 Counter Thresholds: 815 N1: This threshold is the maximum number of retransmissions of PVC 816 status indication before informing the management system of any problem. 817 The default value is 255 retransmissions. 819 N2: This threshold is the maximum number of retransmissions of the PVC 820 keep-alive indication message before informing the management system of 821 any problem. The default value is 255 retransmissions. 823 N3: This threshold is the maximum number of retransmissions of the PVC 824 status indication message with the D bit set to 1 (PVC to be deleted) 825 before considering the PVC to be deleted and before informing the 826 management system The default value is 15 retransmissions. 828 8. Configuration prerequisites 830 Since frame relay VCs are bi-directional and carry traffic in the two 831 opposite directions, at least one pair of tunnel PSN must be available 832 between two PEs with appropriate traffic and QoS capabilities before 833 they can start sending FRoPW packets. Some PSN tunnels require to be 834 created and maintained, other do not. Establishing, maintaining and 835 releasing PSN tunnel are outside the scope of this document. Binding 836 between a pair of frame relay interfaces/DLCI and a PW is done when the 837 PW and FR VC segments are created. 839 In addition a PE must be configured with the following parameters per 840 tunnel PSN. These parameters will apply to all Frame Relay PWs nested 841 inside the tunnel PSN: 843 1. Maximum transfer unit (MTU) of the PSN, 844 2. Whether segmentation and re-assembly will be supported or not, 845 3. Use of the sequence number: With segmentation only, always or never, 846 4. Additional configuration parameters specific to each PW and PSN are 847 listed in the section covering each PSN. 849 9. Frame Relay over MPLS 851 9.1. MPLS tunnel and VC LSPs 853 MPLS label switched paths (LSPs) called "Tunnel LSPs" establish an 854 association between a pair of PEs. A tunnel LSP correspond to a "PSN 855 tunnel" of Figure 1. Several "Virtual Circuit LSPs" (VC LSPs) may be 856 nested inside one Tunnel LSP. Each VC LSP carries the traffic of a frame 857 relay PVC or SVC in one direction. Since LSPs are uni-directional, a 858 pair of VC LSPs (and corresponding tunnel LSPs) carrying traffic in 859 opposite directions will be required usually for each frame relay PVC or 860 SVC. 862 9.2. Relationship between FR VCs and MPLS VC LSPs 864 Frame Relay VCs are considered to be bi-directional objects mainly 865 because of the way they are created and identified. A single frame relay 866 identifier (DLCI) refers to the two directions of a frame relay VC and 867 frame relay signalling establishes the two directions simultaneously 868 with the same message flows. In general each direction of a frame relay 869 VC may have different traffic and QoS characteristics. The resource 870 management of a frame relay implementation treats each direction 871 separately and independently. MPLS LSPs, on the other hand are uni- 872 directional and are established separately. 874 In the case of frame relay over MPLS, during the creation of a frame 875 relay VC, a pair of VC LSPs will have to be established between two PEs. 876 For one end-to-end frame relay VC two VC LSPs exists: One VC LSP to 877 transport the traffic from PE1 to PE2 and another one to transport the 878 traffic in the opposite direction. The VC LSP in each direction must 879 comply with the characteristics of the corresponding direction of the 880 frame relay VC. 882 The VC LSP from PE1 to PE2 is the transmit VC LSP for PE1 and the 883 receive LSP for PE2. Likewise, the VC LSP from PE2 to PE1 is the 884 transmit LSP for PE2 and the receive LSP for PE1. 886 In the frame relay domain, a DLCI identifies a frame relay VC and in the 887 MPLS domain, VC LSP labels with possibly different values identify the 888 pair of VC LSPs, one label value for each LSP. 890 In PE1 to PE2 direction a tunnel LSP gets MPLS packets from PE1 to PE2, 891 the corresponding label is not related to any frame relay VC. When PE1 892 sends a FRoPW packet to PE2, it first pushes a VC label on its label 893 stack, and then pushes on a tunnel LSP label. The VC label is not 894 visible until the FRoPW packet reaches PE2. PE2 forwards FRoPW packet 895 based on the LSP VC label. The VC label must be always at the bottom of 896 the label stack. While the packet is transported across the MPLS 897 network, additional labels may be pushed on (and then popped off) as 898 needed. The processing is similar in the opposite direction from PE2 to 899 PE1. 901 9.3. Frame relay over MPLS packet format 903 In the case of frame relay over MPLS, the generic FroPW packet format of 904 Figure 2 becomes as shown in Figure 5. 906 +-------------------------------+ 907 | Tunnel LSP label(s) | n words (4n bytes per label) 908 +-------------------------------+ 909 | VC LSP label | 1 word 910 +-------------------------------+ 911 | FRoPW Header | 912 | (See Figure 3) | 1 word 913 +-------------------------------+ 914 | Payload packet | 915 |(Q.922 frame information field)| Maximum N bytes 916 | | (to be specified) 917 +-------------------------------+ 919 Figure 5 - Frame relay over MPLS packet format 921 (Section to be completed} 923 10. Frame Relay over IP 925 {Section and subsections to be completed) 927 Note both IP v4 and IP v6 are supported. 929 10.1. General aspects of frame relay over IP 931 10.2 Frame relay over IP packet format 933 For frame relay over IP v4 or v6, the packet format is shown in Figure 934 6. 936 +-------------------------------+ 937 | IP v4 or v6 header | n words 938 +-------------------------------+ 939 | Frame relay PW | 940 | identifier (See Figure 7) | 1 word 941 +-------------------------------+ 942 | FRoPW Header | 943 | (See Figure 3) | 1 word 944 +-------------------------------+ 945 | Payload packet | 946 |(Q.922 frame information field)| Maximum N bytes 947 | | (to be specified) 948 +-------------------------------+ 950 Figure 6 - Frame relay over IP packet format 952 Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 954 Frame relay PW identifier field shown in Figure 6 is used to identify a 955 frame relay VC between two PEs in the case of frame relay over IP. The 956 format of this field is shown in Figure 7. Actually the format is 957 similar to MPLS LSP label format. This format allows to have one size 958 for identifying a frame relay VC between two PEs, instead of having two 959 formats as allowed in FRF.1.2 and FRF.2.2 (see [Q922, FRF1 and FRF2]). 960 The use of the other fields will be described in a subsequent version of 961 this draft. 963 0 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | FR PW Identifier | Exp |0| TTL | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Identifier: Frame relay PW identifier, 20 bits 970 Exp: Experimental Use, 3 bits 971 TTL: Time to Live, 8 bits 973 Figure 7 - frame relay PW identifier for frame relay over IP 975 10.3. Frame relay over IP specific packet processing 977 (To be completed). 979 10.4. Additional configuration objects for frame relay over IP 981 (To be completed). 983 11. Frame Relay over GRE 984 (Section and subsections to be completed). 986 11.1. General aspects of frame relay over GRE 988 11.2. Frame relay over GRE packet format 990 For frame relay over GRE [RFC2784, RFC2890], the packet format is 991 similar to frame relay over IP packet format shown in Figure 6, except 992 that there is one or more additional GRE header(s) as shown in Figure 8. 994 +-------------------------------+ 995 | IP v4 or v6 header | n words 996 +-------------------------------+ 997 | Frame relay PW | 998 | identifier (See Figure 7) | 1 word 999 +-------------------------------+ 1000 | GRE header(s) | m words (m >=1) 1001 | | 1002 +-------------------------------+ 1003 | FRoPW Header | 1004 | (See Figure 3) | 1 word 1005 +-------------------------------+ 1006 | Payload packet | 1007 |(Q.922 frame information field)| Maximum N bytes 1008 | | (to be specified) 1009 +-------------------------------+ 1011 Figure 8 - Frame relay over GRE packet format 1013 11.3. Frame relay over GRE specific packet processing 1015 11.4. Additional configuration objects for frame relay over GRE 1017 12. Frame Relay over L2TP 1019 (To be completed). 1021 13. Security Considerations 1023 (To be completed). 1025 14. References 1027 [I233] ITU-T Recommendation I.233.1, ISDN frame relay bearer 1028 service, Geneva, October 1991 1030 [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, 1031 Frame Relay Forum, April 2000 1033 [FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, 1034 Frame Relay Forum, 2001 1036 [FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement, Frame 1037 Relay Forum, January 2000 1039 [FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement, 1040 Frame Relay Forum, January 2000 1042 [PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3- 1043 requirements-01.txt, July 2001 1045 [PWE3FW] Prayson Pate, et al., Internet draft, Framework for 1046 Pseudo Wire Emulation Edge-to-Edge (PWE3) 1048 [Q922] ITU-T Recommendation Q.922, ISDN Data Link Layer 1049 Specification for Frame Mode Bearer Services, ITU, 1050 Geneva, 1992. 1052 [Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification 1053 for Frame Mode Bearer Services, Geneva, October 1995. 1055 [RFC3032] E. Rosen, et al., RFC 3032 MPLS Label Stack encoding, 1056 January 2001. 1058 [RFC3031] E. Rosen, et al., RFC 3031 MPLS Architecture, January 1059 2001. 1061 [RFC2615] A. G. Malis, RFC 2615 PPP over SONET/SDH, June 1999. 1063 [RFC2784] D. Farinacci, et. al, RFC 2784 Generic routing 1064 encapsulation, March 2000 1066 [RFC2890] G. Dommety, RFC 2890 Key and sequence number extensions 1067 to GRE, September 2000 1069 [X36] ITU-T Recommendation X.36, Interface between a DTE 1070 and DCE for public data networks providing frame relay, 1071 Geneva, 2000 1073 [X76] ITU-T Recommendation X.76, Network-to-network interface 1074 between public data networks providing frame relay 1075 services, Geneva, 2000 1077 15. Acknowledgements 1079 To be completed. 1081 16. Author's Addresses 1083 Claude Kawa 1084 Nortel Networks 1085 3500 Carling Ave. 1086 Ottawa, Ontario, Canada 1087 email: kawa@nortelnetworks.com 1088 Andrew G. Malis 1089 Vivace Networks, Inc. 1090 2730 Orchard Parkway 1091 San Jose, CA 95134 1092 e-mail: Andy.Malis@vivacenetworks.com 1094 Prayson Pate 1095 Overture Networks 1096 P. O. Box 14864 1097 RTP, NC, USA 27709 1098 email: prayson.pate@overturenetworks.com 1100 Ravi Bhat 1101 Amber Networks 1102 50 Vanivalas Road 1103 Bangalore 560 004 India 1104 email: rbhat@ambernetworks.com 1106 Nishit Vasavada 1107 Amber Networks 1108
1109 email: nishit@ambernetworks.com