idnits 2.17.1 draft-ietf-gsmp-encaps-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. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '2' is defined on line 253, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-03 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1700 (ref. '4') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tom Worster 2 INTERNET DRAFT Ennovate Networks 3 Standards Track Expires June 24 2000 5 GSMP Packet Encapsulations for ATM, Ethernet and TCP 7 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as "work 21 in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This memo specifies the encapsulation of GSMP packets in ATM, 32 Ethernet and TCP. 34 1. Introduction 36 GSMP packets are defined in [1] and may be encapsulated in several 37 different protocols for transport. This memo specifies their 38 encapsulation in ATM AAL-5, in Ethernet or in TCP. Other 39 encapsulations may be defined elsewhere. 41 2. ATM Encapsulation 43 GSMP packets are variable length and for an ATM data link layer 44 they are encapsulated directly in an AAL-5 CPCS-PDU [3] with an 45 LLC/SNAP header as illustrated: 47 0 1 2 3 48 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 49 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 50 | LLC (0xAA-AA-03) | | 51 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 52 | SNAP (0x00-00-00-88-0C) | 53 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 54 | | 55 ~ GSMP Message ~ 56 | | 57 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 58 | Pad (0 - 47 octets) | 59 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60 | | 61 + AAL-5 CPCS-PDU Trailer (8 octets) + 62 | | 63 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 65 (The convention in the documentation of Internet Protocols [4] is 66 to express numbers in decimal. Numbers in hexadecimal format are 67 specified by prefacing them with the characters "0x". Numbers in 68 binary format are specified by prefacing them with the characters 69 "0b". Data is pictured in "big-endian" order. That is, fields are 70 described left to right, with the most significant octet on the 71 left and the least significant octet on the right. Whenever a 72 diagram shows a group of octets, the order of transmission of 73 those octets is the normal order in which they are read in 74 English. Whenever an octet represents a numeric quantity the left 75 most bit in the diagram is the high order or most significant bit. 76 That is, the bit labelled 0 is the most significant bit. 77 Similarly, whenever a multi-octet field represents a numeric 78 quantity the left most bit of the whole field is the most 79 significant bit. When a multi-octet quantity is transmitted, the 80 most significant octet is transmitted first. This is the same 81 coding convention as is used in the ATM layer [1] and AAL-5 [3].) 83 The LLC/SNAP header contains the octets: 0xAA 0xAA 0x03 0x00 0x00 84 0x00 0x88 0x0C. (0x880C is the assigned Ethertype for GSMP.) 86 The maximum transmission unit (MTU) of the GSMP Message field is 87 1492 octets. 89 The virtual channel over which a GSMP session is established 90 between a controller and the switch it is controlling is called 91 the GSMP control channel. The default VPI and VCI of the GSMP 92 control channel for LLC/SNAP encapsulated GSMP messages on an ATM 93 data link layer is: 95 VPI = 0 96 VCI = 15. 98 3. Ethernet Encapsulation 100 GSMP packets may be encapsulated on an Ethernet data link as 101 illustrated: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Destination Address | 107 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 110 | Source Address | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Ethertype (0x88-0C) | | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 114 | | 115 ~ GSMP Message ~ 116 | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Sender Instance | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Receiver Instance | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Pad | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Frame Check Sequence | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Destination Address 128 For the SYN message of the adjacency protocol the 129 Destination Address is the broadcast address 130 0xFFFFFFFFFFFF. (Alternatively, it is also valid to 131 configure the node with the unicast 48-bit IEEE MAC 132 address of the destination. In this case the configured 133 unicast Destination Address is used in the SYN message.) 134 For all other messages the Destination Address is the 135 unicast 48- bit IEEE MAC address of the destination. 136 This address may be discovered from the Source Address 137 field of messages received during synchronisation of the 138 adjacency protocol. 140 Source Address 141 For all messages the Source Address is the 48-bit IEEE 142 MAC address of the sender. 144 Ethertype The assigned Ethertype for GSMP is 0x880C. 145 GSMP Message 146 The maximum transmission unit (MTU) of the GSMP Message 147 field is 1492 octets. 149 Sender Instance 150 The Sender Instance number for the link obtained from 151 the adjacency protocol. This field is already present in 152 the adjacency protocol message. It is appended to all 153 non- adjacency GSMP messages in the Ethernet 154 encapsulation to offer additional protection against the 155 introduction of corrupt state. 157 Receiver Instance 158 The Receiver Instance number is what the sender believes 159 is the current instance number for the link, allocated 160 by the entity at the far end of the link. This field is 161 already present in the adjacency protocol message. It is 162 appended to all non-adjacency GSMP messages in the 163 Ethernet encapsulation to offer additional protection 164 against the introduction of corrupt state. 166 Pad 167 The minimum length of the data field of an Ethernet 168 packet is 46 octets. If necessary, padding should be 169 added such that it meets the minimum Ethernet frame 170 size. This padding should be octets of zero and it is 171 not considered to be part of the GSMP message. 173 After the adjacency protocol has achieved synchronisation, for 174 every GSMP message received with an Ethernet encapsulation, the 175 receiver must check the Source Address from the Ethernet MAC 176 header, the Sender Instance, and the Receiver Instance. The 177 incoming GSMP message must be discarded if the Sender Instance and 178 the Source Address do not match the values of Sender Instance and 179 Sender Name stored by the "Update Peer Verifier" operation of the 180 GSMP adjacency protocol. The incoming GSMP message must also be 181 discarded if it arrives over any port other than the port over 182 which the adjacency protocol has achieved synchronisation. In 183 addition, the incoming message must also be discarded if the 184 Receiver Instance field does not match the current value for the 185 Sender Instance of the GSMP adjacency protocol. 187 4. TCP/IP Encapsulation 189 GSMP messages may be transported over an IP network using the TCP 190 encapsulation. TCP provides reliable transport, network flow 191 control, and end-system flow control suitable for networks that 192 may have high loss and variable or unpredictable delay. The GSMP 193 encapsulation in TCP/IP also provides sender authentication using 194 an MD5 digest. 196 For TCP encapsulations of GSMP messages, the controller runs the 197 client code and the switch runs the server code. Upon 198 initialisation, the server is listening on GSMP's (proposed) well 199 known port number. The controller establishes a TCP connection 200 with each switch it manages. Adjacency protocol messages, which 201 are used to synchronise the controller and switch and maintain 202 handshakes, are sent by the controller to the switch after the TCP 203 connection is established. GSMP messages other than adjacency 204 protocol messages may be sent only after the adjacency protocol 205 has achieved synchronisation. 207 4.1 Message Formats 209 GSMP messages are sent over a TCP connection. A GSMP message is 210 processed only after it is entirely received. A four-byte TLV 211 header field is prepended to the GSMP message to provide 212 delineation of GSMP messages within the TCP stream. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type (0x88-0C) | Length | 218 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 ~ GSMP Message ~ 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Type 225 This 2-octet field indicates the type code of the 226 following message. The type code for GSMP messages is 227 0x00-0C (i.e. the same as GSMP's Ethertype). 229 Length: This 2-octet unsigned integer indicates the total length 230 of the GSMP message only. It does not including the 4- 231 byte TLV header. 233 4.2 Security consideration 235 To ensure the authenticity and security of GSMP messages which are 236 transported through an IP network standard security measures 237 should be used. GSMP provides for a two-layer security mechanism. 238 The first layer of security mechanism is applied to network layer 239 using IP-Sec (RFC 2401) [5]. 241 5. Security Considerations 243 The security of GSMP's TCP/IP control channel has been addressed 244 in Section 4.2. Security over ATM and Ethernet must be provided at 245 the link layer. [need some more detail on minimum ip sec 246 requirements -- ed] 248 References 250 [1] T. Worster, "General Switch Management Protocol," 251 Internet-Draft draft-ietf-gsmp-03, Jan 2000. 253 [2] "B-ISDN ATM Layer Specification," International 254 Telecommunication Union, ITU-T Recommendation I.361, Mar. 255 1993. 257 [3] "B-ISDN ATM Adaptation Layer (AAL) Specification," 258 International Telecommunication Union, ITU-T 259 Recommendation I.363, Mar. 1993. 261 [4] Reynolds, J., and J. Postel, "Assigned Numbers," STD 2, 262 RFC 1700, October 1994. 264 [5] IP 265 Sec 266 [together with text above, ip sec refs -- ed] 268 Authors' Addresses 270 Tom Worster 271 Ennovate Networks 272 60 Codman Hill Rd 273 Boxboro MA 01719 USA 274 Tel +1 978-263-2002 275 fsb@thefsb.org