idnits 2.17.1 draft-martini-l2circuit-trans-mpls-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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 1999) is 8892 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: '3' is defined on line 302, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-06 -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-07 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Luca Martini 2 Internet Draft Nasser El-Aawar 3 Expiration Date: June 2000 Level 3 Communications, LLC. 5 Dimitri Stratton Vlachos 6 Daniel Tappan 7 Eric C. Rosen 8 Cisco Systems, Inc. 10 December 1999 12 Transport of Layer 2 Frames Over MPLS 14 draft-martini-l2circuit-trans-mpls-00.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document described a method for transporting the Protocol Data 40 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, and 41 ethernet across an MPLS network. 43 Table of Contents 45 1 Specification of Requirements .......................... 2 46 2 Introduction ........................................... 2 47 3 Tunnel Labels and VC Labels ............................ 2 48 4 Optional Sequencing and/or Padding ..................... 4 49 5 Protocol-Specific Issues ............................... 5 50 5.1 Frame Relay ............................................ 5 51 5.2 ATM AAL5 ............................................... 5 52 5.3 Ethernet ............................................... 6 53 6 LDP .................................................... 6 54 7 Security Considerations ................................ 7 55 8 References ............................................. 7 56 9 Author Information ..................................... 8 58 1. Specification of Requirements 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119. 64 2. Introduction 66 In an MPLS network, it is possible to carry the Protocol Data Units 67 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 68 these PDUs. This document specifies the necessary label distribution 69 and encapsulation procedures for accomplishing this. We restrict 70 discussion to the case of point-to-point transport. QoS related 71 issues are not discussed in this draft. 73 3. Tunnel Labels and VC Labels 75 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 76 to egress LSR R2, across an intervening MPLS network. We assume that 77 there is an LSP from R1 to R2. That is, we assume that R1 can cause 78 a packet to be delivered to R2 by pushing some label onto the packet 79 and sending the result to one of its adjacencies. Call this label 80 the "tunnel label", and the corresponding LSP the "tunnel LSP". 82 The tunnel LSP merely gets packets from R1 to R2, the corresponding 83 label doesn't tell R2 what to do with the payload, and in fact if 84 penultimate hop popping is used, R2 may never even see the 85 corresponding label. (If R1 itself is the penultimate hop, a tunnel 86 label may not even get pushed on.) Thus if the payload is not an IP 87 packet, there must be a label, which becomes visible to R2, that 88 tells R2 how to treat the received packet. Call this label the "VC 89 label". 91 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 92 its label stack, and then (if R1 is not adjacent to R2) pushes on a 93 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 94 the VC label is not visible until the MPLS packet reaches R2. R2's 95 disposition of the packet is based on the VC label. 97 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 98 the VC label will generally correspond to a particular ATM VC at R2. 99 That is, R2 needs to be able to infer from the VC label the outgoing 100 interface and the VPI/VCI value for the AAL5 PDU. If the payload is 101 a Frame Relay PDU, then R2 needs to be able to infer from the VC 102 label the outgoing interface and the DLCI value. If the payload is 103 an ethernet frame, then R2 needs to be able to infer from the VC 104 label the outgoing interface, and perhaps the VLAN identifier. 106 Note that the VC label must always be at the bottom of the label 107 stack, and the tunnel label, if present, must be immediately above 108 the VC label. Of course, as the packet is transported across the 109 MPLS network, additional labels may be pushed on (and then popped 110 off) as needed. Even R1 itself may push on additional labels above 111 the tunnel label. If R1 and R2 are directly adjacent LSRs, then it 112 may not be necessary to use a tunnel label at all. 114 This document does not specify a method for distributing the tunnel 115 label or any other labels that may appear above it on the stack. Any 116 acceptable method of MPLS label distribution will do. 118 This document does specify a method for assigning and distributing 119 the VC label. Static label assignment MAY be used, and 120 implementations SHOULD provide support for this. If signalling is 121 used, the VC label MUST be distributed from R2 to R1 using LDP in the 122 downstream unsolicited mode; this requires that an LDP connection be 123 created between R1 and R2. 125 Note that this technique allows an unbounded number of layer 2 "VCs" 126 to be carried together in a single "tunnel". Thus it scales quite 127 well in the network backbone. 129 4. Optional Sequencing and/or Padding 131 Sometimes it is important to guarantee that sequentiality is 132 preserved on a layer 2 virtual circuit. To accommodate this 133 requirement, we provide an optional control word which may appear 134 immediately after the label stack and immediately before the layer 2 135 PDU. This control word contains a sequence number. R1 and R2 both 136 need to be configured with the knowledge of whether a control word 137 will be used for a specific virtual circuit. 139 Sometimes it is necessary to transmit a small packet on a medium 140 where there is a minimum transport unit larger than the actual packet 141 size. In this case, padding is appended to the packet. When the VC 142 label is popped, it may be desirable to remove the padding before 143 forwarding the packet. 145 To facilitate this, the control word has a length field. If the 146 packet's length (without any padding) is less than 256 bytes, the 147 length field MUST be set to the packet's length (without padding). 148 Otherwise the length field MUST be set to zero. The value of the 149 length field, if non-zero, can be used to remove any padding. 151 The control word is defined as follows: 153 0 1 2 3 154 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 2 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Reserved | Length | Sequence Number | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 The first 8 bits are reserved for future use. They MUST be set to 0 160 when transmitting, and MUST be ignored upon receipt. The length byte 161 is set as specified above. 163 The next 16 bits are the sequence number that is used to guarantee 164 ordered packet delivery. For a given VC label, and a given pair of 165 LSRs, R1 and R2, where R2 has distributed that VC label to R1, the 166 sequence number is initialized to 0, and is incremented by one for 167 each successive packet carrying that VC label which R1 transmits to 168 R2. 170 The sequence number space is a 16 bit unsigned circular space. PDUs 171 carrying the control word MUST NOT be delivered out of order. They 172 may be discarded or reordered. 174 5. Protocol-Specific Issues 176 5.1. Frame Relay 178 A Frame Relay PDU is transported in its entirety, including the Frame 179 Relay Header. The sequencing control word is optional. 181 The BCN and FCN signals are carried unchanged across the network in 182 the frame relay header. These signals do not appear in the MPLS 183 header, and are unseen by the MPLS network. 185 If the MPLS edge LSR detects a service affecting condition as defined 186 in [2] Q.933 Annex A.5 sited in IA FRF1.1, it will withdraw the label 187 that corresponds to the frame relay DLCI. The Egress side should 188 generate the corresponding errors and alarms as defined in [2] on the 189 Frame relay VC. 191 The ingress LSR MAY consider the DE bit of the Frame Relay header 192 when determining the value to be placed in the EXP fields of the MPLS 193 label stack. 195 5.2. ATM AAL5 197 Only ATM Adaptation Layer 5 (AAL5) is supported. A CPCS-PDU is 198 transported as a single packet without segmentation. No AAL5 trailer 199 is transported. The sequencing control word is optional. 201 If the edge LSR receives an AIS F5 OAM cell, or fails to receive a 202 pre-defined number of the End-to-End loop OAM cells, or the physical 203 interface is down, it will withdraw the LSP mapping for the VC 204 associated with the failure. The egress LSR will generate AIS F5 OAM, 205 or stop returning/forwarding the End-to-End loop OAM Cells to the 206 remote destination of the VC associated with the withdrawn LSP. 208 The ingress LSR MAY consider the CLP bit when determining the value 209 to be placed in the EXP fields of the MPLS label stack. 211 The egress LSR MAY consider the value of the EXP field of the VC 212 label when determining the value of the ATM CLP bit. 214 5.3. Ethernet 216 If the VC label corresponds just to an ethernet interface, then the 217 ethernet frame is sent in its entirety. If the VC label corresponds 218 to a particular VLAN, however, then the VLAN tag should be removed. 220 6. LDP 222 The VC label bindings are distributed using the LDP downstream 223 unsolicited mode described in [1]. The LSRs will establish and LDP 224 session using the Extended Discovery mechanism described in [1, 225 section 2.4-2.5] 227 A new type of FEC TLV, a VC FEC Element is defined as follows: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | VC tlv | VC Type | VC ID len | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Group ID | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 | VC ID | 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 - VC Type 243 A two octet quantity containing a value which represents the type 244 of VC. Assigned Values are: 246 1 - Frame Relay DLCI 247 2 - ATM PVC 248 3 - Ethernet 249 4 - Ethernet VLAN 250 5 - HDLC 251 6 - PPP 253 - VC ID length 255 Length of the VC ID field in octets. If this value is 0,then it 256 references all VCs using the specified Link ID 258 - Group ID 260 An arbitrary 32 bit value which represents a group of VCs. 262 - VC ID 264 Identifies a particular VC. The interpretation of the identifier 265 depends on the VC type: 267 * Frame Relay 269 A 16-bit DLCI value. 271 * ATM 273 A 32-bit value representing a 16-bit VPI and a 16-bit VCI. 275 * Ethernet 277 A port identifier (details TBD). 279 * Ethernet VLAN 281 A port identifier plus a VLAN tag (details TBD). 283 * HDLC 285 A port identifier (details TBD). 287 * PPP 289 A port identifier (details TBD). 291 7. Security Considerations 293 This document does not affect the underlying security issues of MPLS. 295 8. References 297 [1] "LDP Specification", draft-ietf-mpls-ldp-06.txt, 10/5/99 299 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 300 Mode Basic call control, ITU Geneva 1995 302 [3] "MPLS Label Stack Encoding", draft-ietf-mpls-label-encaps-07.txt, 303 9/13/99 305 9. Author Information 307 Luca Martini 308 Level 3 Communications, LLC. 309 1025 Eldorado Blvd. 310 Broomfield, CO, 80021 312 Nasser El-Aawar 313 Level 3 Communications, LLC. 314 1025 Eldorado Blvd. 315 Broomfield, CO, 80021 317 Dimitri Stratton Vlachos 318 Cisco Systems, Inc. 319 250 Apollo Drive 320 Chelmsford, MA, 01824 321 e-mail: dvlachos@cisco.com 323 Dan Tappan 324 Cisco Systems, Inc. 325 250 Apollo Drive 326 Chelmsford, MA, 01824 327 e-mail: tappan@cisco.com 329 Eric Rosen 330 Cisco Systems, Inc. 331 250 Apollo Drive 332 Chelmsford, MA, 01824 333 e-mail: erosen@cisco.com