idnits 2.17.1 draft-rfced-info-flowlabel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 73 lines 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. ** The abstract seems to contain references ([IFMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (August 1996) is 10109 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1483 (Obsoleted by RFC 2684) Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Flow Labelled IPv4 on ATM Expires August 1996 4 Internet-Draft P. Newman, Ipsilon 5 W. L. Edwards, Sprint 6 Category: Informational R. Hinden, Ipsilon 7 E. Hoffman, Ipsilon 8 F. Ching Liaw, Ipsilon 9 T. Lyon, Ipsilon 10 G. Minshall, Ipsilon 11 February 1996 13 The Transmission of Flow Labelled IPv4 on ATM Data Links 15 Version 1.0 17 19 Status of this Memo 21 This document is an Internet Draft. Internet Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its Areas, 23 and its Working Groups. Note that other groups may also distribute 24 working documents as Internet Drafts. 26 Internet Drafts are draft documents valid for a maximum of six 27 months. Internet Drafts may be updated, replaced, or obsoleted by 28 other documents at any time. It is not appropriate to use Internet 29 Drafts as reference material or to cite them other than as a 30 "working draft" or "work in progress." 32 To learn the current status of any Internet-Draft, please check the 33 "1id-abstracts.txt" listing contained in the internet-drafts Shadow 34 Directories on: 36 ftp.is.co.za (Africa) 37 nic.nordu.net (Europe) 38 ds.internic.net (US East Coast) 39 ftp.isi.edu (US West Coast) 40 munnari.oz.au (Pacific Rim) 42 Abstract 44 This document specifies the manner for transmitting IPv4 datagrams 45 over an ATM data link, both in a default manner and in the presence 46 of flow labelling via Ipsilon Flow Management Protocol [IFMP]. 48 Table of Contents 50 Introduction....................................................2 51 1. Labels.......................................................2 52 2. Default Encapsulation........................................2 53 3. Flow Type 0 Encapsulation....................................3 54 4. Flow Type 1 Encapsulation....................................4 55 5. Flow Type 2 Encapsulation....................................5 56 References......................................................7 58 Introduction 60 This document specifies the manner for transmitting IPv4 datagrams 61 over an ATM data link, both in a default manner and in the presence 62 of flow labelling via Ipsilon Flow Management Protocol [IFMP]. ATM 63 specific functions such as OAM cells, the CLP bit, and ABR RM cells 64 are not used. There are no reserved VCIs other than VPI = 0, VCI = 65 0, which indicates an unassigned cell; and VPI = 0, VCI = 16, which 66 is used for the default encapsulation. IFMP messages must be sent 67 using the default encapsulation. 69 1. Labels 71 Labels, as carried by IFMP, are realized on an ATM data link as 72 specific VPI/VCIs. The format of the Label field for ATM labels is: 74 0 1 2 3 75 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 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 |Reservd| VPI | VCI | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 The low order 16 bits of the label correspond to the VCI, with the 81 least significant bit of the Label field corresponding to the least 82 significant bit of the VCI. If the link cannot support a full 16 bit 83 VCI the unused bits of the VCI must be the most significant bits and 84 they must be set to zero. 86 The next 12 higher order bits of the label correspond to the VPI, 87 with the least significant of these bits corresponding to the least 88 significant bit of the VPI. If the link cannot support a full 12 bit 89 VPI, then the unused bits of the VPI must be the most significant 90 bits and they must be set to zero. The most significant four bits of 91 the label are reserved. They should be set to zero by the sender and 92 ignored by the receiver. 94 2. Default Encapsulation 96 The default encapsulation for IPv4 packets on ATM data links is the 97 LLC/SNAP encapsulation specified in section 4.1 "LLC encapsulation 98 for routed protocols" of RFC 1483 [RFC1483]. Such frames begin with 99 the octets 0xAA 0xAA 0x03 0x00 0x00 0x00 0x08 0x00 (the LLC/SNAP 100 header for IPv4). The LLC/SNAP header is prefixed to the IP datagram 101 and the entire packet is encapsulated within the payload of an AAL-5 102 CPCS-PDU as specified in RFC 1483 and illustrated below: 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | LLC (0xAA-AA-03) | | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 109 | SNAP (0x00-00-00-08-00) | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | | 112 ~ IPv4 Datagram ~ 113 | | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Pad (0 - 47 octets) | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | 118 + AAL-5 CPCS-PDU Trailer (8 octets) + 119 | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 The maximum transmission unit (MTU) of an IPv4 datagram using the 123 default encapsulation is 1500 octets. 125 Frames using the default encapsulation are sent to: VPI = 0, VCI = 126 16. 128 3. Flow Type 0 Encapsulation 130 All IPv4 frames using Flow Type 0 are encapsulated within the payload 131 of an AAL-5 CPCS-PDU. This is the null encapsulation of section 5.1 132 "VC based multiplexing of routed protocols" from RFC 1483 [RFC1483]. 133 There is no LLC/SNAP header. The first octet of the frame 134 corresponds to the first octet of the IPv4 datagram (i.e., the octet 135 that contains the IP version number (4) and Internet Header Length 136 (IHL) ). The IP datagram is encapsulated within the payload of an 137 AAL-5 CPCS-PDU as specified in RFC 1483 and illustrated below: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | 143 ~ IPv4 Datagram ~ 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Pad (0 - 47 octets) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 + AAL-5 CPCS-PDU Trailer (8 octets) + 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 The MTU of an IPv4 datagram using Flow Type 0 encapsulation is 1500 154 octets. 156 Frames using Flow Type 0 encapsulation are sent to the VPI/VCI 157 specified in the Label field of the corresponding IFMP Flow Type 0 158 Redirect message element [IFMP]. 160 4. Flow Type 1 Encapsulation 162 All IPv4 frames using Flow Type 1 are encapsulated directly in the 163 payload of an AAL-5 CPCS-PDU. This is the null encapsulation of 164 section 5.1 "VC based multiplexing of routed protocols" from RFC 1483 165 [RFC1483]. There is no LLC/SNAP header. Also, the following fields 166 of the IP header are not transmitted: Version, Internet Header Length 167 (IHL), Type of Service (TOS), Time to Live (TTL), Protocol, Source 168 Address, and Destination Address. In addition, the first 4 octets 169 immediately following the IP header (as determined by the IHL field) 170 are not transmitted. (These 4 octets correspond to the source and 171 destination ports for TCP and UDP datagrams.) The value of the Total 172 Length field is not changed; it remains the total length of the IP 173 datagram before the above fields were removed. The transmitted value 174 of the Checksum field is the checksum value that would have been 175 computed for the entire IP header if the TTL field had been set to 176 zero (i.e., the actual value of the TTL field is "subtracted", using 177 one's-complement arithmetic, from the Checksum before transmission). 179 The IP datagram is encapsulated within the payload of an AAL-5 CPCS- 180 PDU as specified in RFC 1483 and illustrated below: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Total Length | Identification | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |Flags| Fragment Offset | Checksum | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 ~ Data ~ 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Pad (0 - 47 octets) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | | 196 + AAL-5 CPCS-PDU Trailer (8 octets) + 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 The MTU of the IPv4 datagram using Flow Type 1 encapsulation is 1484 201 octets (1500 octets minus the 16 octets specified above). 203 Frames using Flow Type 1 encapsulation are sent to the VPI/VCI 204 specified in the Label field of the corresponding IFMP Flow Type 1 205 redirect message element [IFMP]. 207 5. Flow Type 2 Encapsulation 209 All IPv4 frames using Flow Type 2 are encapsulated directly in the 210 payload of an AAL-5 CPCS-PDU. This is the null encapsulation of 211 section 5.1 "VC based multiplexing of routed protocols" from RFC 1483 212 [RFC1483]. There is no LLC/SNAP header. Also, the following fields 213 of the IP header are not transmitted: Version, Internet Header Length 214 (IHL), Time to Live (TTL), Source Address, and Destination Address. 215 The first 4 octets immediately following the IP header (as determined 216 by the IHL field) are transmitted. (These 4 octets correspond to the 217 source and destination ports for TCP and UDP datagrams.) The value of 218 the Total Length field is not changed; it remains the total length of 219 the IP datagram before the above fields were removed. The 220 transmitted value of the Checksum field is the checksum value that 221 would have been computed for the entire IP header if the TTL field 222 had been set to zero (i.e., the actual value of the TTL field is 223 "subtracted", using one's-complement arithmetic, from the Checksum 224 before transmission). 226 The IP datagram is encapsulated within the payload of an AAL-5 CPCS- 227 PDU as specified in RFC 1483 and illustrated below: 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 | Reserved |Type of Service| Total Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Identification |Flags| Fragment Offset | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Reserved | Protocol | Checksum | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 ~ Data ~ 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Pad (0 - 47 octets) | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 + AAL-5 CPCS-PDU Trailer (8 octets) + 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 The Reserved fields are not used and should be set to zero by the 250 sender and ignored by the receiver. 252 The MTU of the IPv4 datagram using Flow Type 2 encapsulation is 1492 253 octets (1500 octets minus the 8 octets specified above). 255 Frames using Flow Type 2 encapsulation are sent to the VPI/VCI 256 specified in the Label field of the corresponding IFMP Flow Type 2 257 redirect message element [IFMP]. 259 References 261 [IFMP] P. Newman, et. al., "The IFMP Protocol Specification for 262 IPv4," Ipsilon Networks Inc., RFC-XXXX, February 1996. 264 [RFC1483] J. Heinanen, "Multiprotocol Encapsulation over ATM 265 Adaptation Layer 5", RFC 1483, July 1993. 267 SECURITY CONSIDERATIONS 269 Security issues are not discussed in this document. 271 AUTHORS' ADDRESSES 273 Peter Newman Phone: +1 (415) 846-4603 274 Ipsilon Networks, Inc. Email: pn@ipsilon.com 276 W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334 277 Sprint Email: texas@sprintcorp.com 279 Robert M. Hinden Phone: +1 (415) 846-4604 280 Ipsilon Networks, Inc. Email: hinden@ipsilon.com 282 Eric Hoffman Phone: +1 (415) 846-4610 283 Ipsilon Networks, Inc. Email: hoffman@ipsilon.com 285 Fong Ching Liaw Phone: +1 (415) 846-4607 286 Ipsilon Networks, Inc. Email: fong@ipsilon.com 288 Tom Lyon Phone: +1 (415) 846-4601 289 Ipsilon Networks, Inc. Email: pugs@ipsilon.com 291 Greg Minshall Phone: +1 (415) 846-4605 292 Ipsilon Networks, Inc. Email: minshall@ipsilon.com 294 Ipsilon Networks, Inc. is located at: 296 2191 East Bayshore Road 297 Suite 100 298 Palo Alto, CA 94303 299 USA 301 Sprint is located at: 303 Sprint 304 Sprint Technology Services - Long Distance Division 305 9300 Metcalf Avenue 306 Mailstop KSOPKB0802 307 Overland Park, KS 66212-6333 308 USA