From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1954.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc1954.txt (limited to 'doc/rfc/rfc1954.txt') diff --git a/doc/rfc/rfc1954.txt b/doc/rfc/rfc1954.txt new file mode 100644 index 0000000..d82f75b --- /dev/null +++ b/doc/rfc/rfc1954.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group P. Newman, Ipsilon +Request for Comments: 1954 W. L. Edwards, Sprint +Category: Informational R. Hinden, Ipsilon + E. Hoffman, Ipsilon + F. Ching Liaw, Ipsilon + T. Lyon, Ipsilon + G. Minshall, Ipsilon + May 1996 + + + Transmission of Flow Labelled IPv4 on ATM Data Links + Ipsilon Version 1.0 + +Status of this Memo + + This document provides information for the Internet community. This + memo does not specify an Internet standard of any kind. Distribution + of this memo is unlimited. + +IESG Note: + + This note documents a private protocol for IPv4-based flows. This + protocol is NOT the product of an IETF working group nor is it a + standards track document. It has not necessarily benefited from the + widespread and in depth community review that standards track + documents receive. + +Abstract + + This document specifies the manner for transmitting IPv4 datagrams + over an ATM data link, both in a default manner and in the presence + of flow labelling via Ipsilon Flow Management Protocol [IFMP]. + +Table of Contents + + Introduction....................................................2 + 1. Labels.......................................................2 + 2. Default Encapsulation........................................2 + 3. Flow Type 0 Encapsulation....................................3 + 4. Flow Type 1 Encapsulation....................................4 + 5. Flow Type 2 Encapsulation....................................5 + References......................................................7 + Security Considerations.........................................7 + Authors' Addresses..............................................7 + + + + + + + +Newman, et. al. Informational [Page 1] + +RFC 1954 Flow Labelled IPv4 on ATM May 1996 + + +Introduction + + This document specifies the manner for transmitting IPv4 datagrams + over an ATM data link, both in a default manner and in the presence + of flow labelling via Ipsilon Flow Management Protocol [IFMP]. ATM + specific functions such as OAM cells, the CLP bit, and ABR RM cells + are not used. There are no reserved VCIs other than VPI = 0, VCI = + 0, which indicates an unassigned cell; and VPI = 0, VCI = 15, which + is used for the default encapsulation. IFMP messages must be sent + using the default encapsulation. + +1. Labels + + Labels, as carried by IFMP, are realized on an ATM data link as + specific VPI/VCIs. The format of the Label field for ATM labels is: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Reservd| VPI | VCI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The low order 16 bits of the label correspond to the VCI, with the + least significant bit of the Label field corresponding to the least + significant bit of the VCI. If the link cannot support a full 16 bit + VCI the unused bits of the VCI must be the most significant bits and + they must be set to zero. + + The next 12 higher order bits of the label correspond to the VPI, + with the least significant of these bits corresponding to the least + significant bit of the VPI. If the link cannot support a full 12 bit + VPI, then the unused bits of the VPI must be the most significant + bits and they must be set to zero. The most significant four bits of + the label are reserved. They should be set to zero by the sender and + ignored by the receiver. + +2. Default Encapsulation + + The default encapsulation for IPv4 packets on ATM data links is the + LLC/SNAP encapsulation specified in section 4.1 "LLC encapsulation + for routed protocols" of RFC 1483 [RFC1483]. Such frames begin with + the octets 0xAA 0xAA 0x03 0x00 0x00 0x00 0x08 0x00 (the LLC/SNAP + header for IPv4). The LLC/SNAP header is prefixed to the IP datagram + and the entire packet is encapsulated within the payload of an AAL-5 + CPCS-PDU as specified in RFC 1483 and illustrated below: + + + + + + +Newman, et. al. Informational [Page 2] + +RFC 1954 Flow Labelled IPv4 on ATM May 1996 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LLC (0xAA-AA-03) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | SNAP (0x00-00-00-08-00) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ IPv4 Datagram ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Pad (0 - 47 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + AAL-5 CPCS-PDU Trailer (8 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The maximum transmission unit (MTU) of an IPv4 datagram using the + default encapsulation is 1500 octets. + + Frames using the default encapsulation are sent to: VPI = 0, VCI = + 15. + +3. Flow Type 0 Encapsulation + + All IPv4 frames using Flow Type 0 are encapsulated within the payload + of an AAL-5 CPCS-PDU. This is the null encapsulation of section 5.1 + "VC based multiplexing of routed protocols" from RFC 1483 [RFC1483]. + There is no LLC/SNAP header. The first octet of the frame + corresponds to the first octet of the IPv4 datagram (i.e., the octet + that contains the IP version number (4) and Internet Header Length + (IHL) ). The IP datagram is encapsulated within the payload of an + AAL-5 CPCS-PDU as specified in RFC 1483 and illustrated below: + + + + + + + + + + + + + + + + + +Newman, et. al. Informational [Page 3] + +RFC 1954 Flow Labelled IPv4 on ATM May 1996 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ IPv4 Datagram ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Pad (0 - 47 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + AAL-5 CPCS-PDU Trailer (8 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The MTU of an IPv4 datagram using Flow Type 0 encapsulation is 1500 + octets. + + Frames using Flow Type 0 encapsulation are sent to the VPI/VCI + specified in the Label field of the corresponding IFMP Flow Type 0 + Redirect message element [IFMP]. + +4. Flow Type 1 Encapsulation + + All IPv4 frames using Flow Type 1 are encapsulated directly in the + payload of an AAL-5 CPCS-PDU. This is the null encapsulation of + section 5.1 "VC based multiplexing of routed protocols" from RFC 1483 + [RFC1483]. There is no LLC/SNAP header. Also, the following fields + of the IP header are not transmitted: Version, Internet Header Length + (IHL), Type of Service (TOS), Time to Live (TTL), Protocol, Source + Address, and Destination Address. In addition, the first 4 octets + immediately following the IP header (as determined by the IHL field) + are not transmitted. (These 4 octets correspond to the source and + destination ports for TCP and UDP datagrams.) The value of the Total + Length field is not changed; it remains the total length of the IP + datagram before the above fields were removed. The transmitted value + of the Checksum field is the checksum value that would have been + computed for the entire IP header if the TTL field had been set to + zero (i.e., the actual value of the TTL field is "subtracted", using + one's-complement arithmetic, from the Checksum before transmission). + + The IP datagram is encapsulated within the payload of an AAL-5 CPCS- + PDU as specified in RFC 1483 and illustrated below: + + + + + + + + + +Newman, et. al. Informational [Page 4] + +RFC 1954 Flow Labelled IPv4 on ATM May 1996 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Total Length | Identification | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Flags| Fragment Offset | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Pad (0 - 47 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + AAL-5 CPCS-PDU Trailer (8 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The MTU of the IPv4 datagram using Flow Type 1 encapsulation is 1484 + octets (1500 octets minus the 16 octets specified above). + + Frames using Flow Type 1 encapsulation are sent to the VPI/VCI + specified in the Label field of the corresponding IFMP Flow Type 1 + redirect message element [IFMP]. + +5. Flow Type 2 Encapsulation + + All IPv4 frames using Flow Type 2 are encapsulated directly in the + payload of an AAL-5 CPCS-PDU. This is the null encapsulation of + section 5.1 "VC based multiplexing of routed protocols" from RFC 1483 + [RFC1483]. There is no LLC/SNAP header. Also, the following fields + of the IP header are not transmitted: Version, Internet Header Length + (IHL), Time to Live (TTL), Source Address, and Destination Address. + The first 4 octets immediately following the IP header (as determined + by the IHL field) are transmitted. (These 4 octets correspond to the + source and destination ports for TCP and UDP datagrams.) The value of + the Total Length field is not changed; it remains the total length of + the IP datagram before the above fields were removed. The + transmitted value of the Checksum field is the checksum value that + would have been computed for the entire IP header if the TTL field + had been set to zero (i.e., the actual value of the TTL field is + "subtracted", using one's-complement arithmetic, from the Checksum + before transmission). + + The IP datagram is encapsulated within the payload of an AAL-5 CPCS- + PDU as specified in RFC 1483 and illustrated below: + + + + + +Newman, et. al. Informational [Page 5] + +RFC 1954 Flow Labelled IPv4 on ATM May 1996 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved |Type of Service| Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification |Flags| Fragment Offset | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Protocol | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Pad (0 - 47 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + AAL-5 CPCS-PDU Trailer (8 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Reserved fields are not used and should be set to zero by the + sender and ignored by the receiver. + + The MTU of the IPv4 datagram using Flow Type 2 encapsulation is 1492 + octets (1500 octets minus the 8 octets specified above). + + Frames using Flow Type 2 encapsulation are sent to the VPI/VCI + specified in the Label field of the corresponding IFMP Flow Type 2 + redirect message element [IFMP]. + + + + + + + + + + + + + + + + + + + + + + +Newman, et. al. Informational [Page 6] + +RFC 1954 Flow Labelled IPv4 on ATM May 1996 + + +References + + [IFMP] Newman, P., et. al., "Ipsilon Flow Management Protocol + Specification for IPv Version 1.0", Ipsilon Networks + Inc., RFC 1953, May 1996. + + [RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM + Adaptation Layer 5", RFC 1483, July 1993. + +SECURITY CONSIDERATIONS + + Security issues are not discussed in this document. + +AUTHORS' ADDRESSES + + Peter Newman Phone: +1 (415) 846-4603 + Ipsilon Networks, Inc. EMail: pn@ipsilon.com + + W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334 + Sprint EMail: texas@sprintcorp.com + + Robert M. Hinden Phone: +1 (415) 846-4604 + Ipsilon Networks, Inc. EMail: hinden@ipsilon.com + + Eric Hoffman Phone: +1 (415) 846-4610 + Ipsilon Networks, Inc. EMail: hoffman@ipsilon.com + + Fong Ching Liaw Phone: +1 (415) 846-4607 + Ipsilon Networks, Inc. EMail: fong@ipsilon.com + + Tom Lyon Phone: +1 (415) 846-4601 + Ipsilon Networks, Inc. EMail: pugs@ipsilon.com + + Greg Minshall Phone: +1 (415) 846-4605 + Ipsilon Networks, Inc. EMail: minshall@ipsilon.com + + + + + + + + + + + + + + + + +Newman, et. al. Informational [Page 7] + +RFC 1954 Flow Labelled IPv4 on ATM May 1996 + + +Ipsilon Networks, Inc. is located at: + + 2191 East Bayshore Road + Suite 100 + Palo Alto, CA 94303 + USA + +Sprint is located at: + + Sprint + Sprint Technology Services - Long Distance Division + 9300 Metcalf Avenue + Mailstop KSOPKB0802 + Overland Park, KS 66212-6333 + USA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newman, et. al. Informational [Page 8] + -- cgit v1.2.3