idnits 2.17.1 draft-ietf-gsmp-encaps-03.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 264: '...oller and client MUST be provided by I...' RFC 2119 keyword, line 266: '... SHOULD be used for the validation of...' RFC 2119 keyword, line 267: '...ty Payload (ESP) MAY be used to provid...' 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 (May 2001) is 8382 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) -- Looks like a reference, but probably isn't: 'IPSEC' on line 265 == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-07 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GSMP Working Group Tom Worster 2 INTERNET DRAFT Ennovate Networks 3 Standards Track Avri Doria 4 Joachim Buerkle 5 November 2000 Nortel Networks 6 Expires May 2001 8 GSMP Packet Encapsulations for ATM, Ethernet and TCP 10 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo specifies the encapsulation of GSMP packets in ATM, 35 Ethernet and TCP. 37 1. Introduction 39 GSMP messages are defined in [1] and may be encapsulated in 40 several different protocols for transport. This memo specifies 41 their encapsulation in ATM AAL-5, in Ethernet or in TCP. Other 42 encapsulations may be defined in future specifications. 44 2. ATM Encapsulation 46 GSMP packets are variable length and for an ATM data link layer 47 they are encapsulated directly in an AAL-5 CPCS-PDU [3][4] with an 48 LLC/SNAP header as illustrated: 50 0 1 2 3 51 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 52 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 53 | LLC (0xAA-AA-03) | | 54 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 55 | SNAP (0x00-00-00-88-0C) | 56 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 57 | | 58 ~ GSMP Message ~ 59 | | 60 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 61 | Pad (0 - 47 bytes) | 62 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 63 | | 64 + AAL-5 CPCS-PDU Trailer (8 bytes) + 65 | | 66 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68 (The convention in the documentation of Internet Protocols [5] is 69 to express numbers in decimal. Numbers in hexadecimal format are 70 specified by prefacing them with the characters "0x". Numbers in 71 binary format are specified by prefacing them with the characters 72 "0b". Data is pictured in "big-endian" order. That is, fields are 73 described left to right, with the most significant byte on the 74 left and the least significant byte on the right. Whenever a 75 diagram shows a group of bytes, the order of transmission of 76 those bytes is the normal order in which they are read in 77 English. Whenever an byte represents a numeric quantity the left 78 most bit in the diagram is the high order or most significant bit. 79 That is, the bit labelled 0 is the most significant bit. 80 Similarly, whenever a multi-byte field represents a numeric 81 quantity the left most bit of the whole field is the most 82 significant bit. When a multi-byte quantity is transmitted, the 83 most significant byte is transmitted first. This is the same 84 coding convention as is used in the ATM layer [2] and AAL-5 85 [3][4].) 87 The LLC/SNAP header contains the bytes: 0xAA 0xAA 0x03 0x00 0x00 88 0x00 0x88 0x0C. (0x880C is the assigned Ethertype for GSMP.) 90 The maximum transmission unit (MTU) of the GSMP Message field is 91 1492 bytes. 93 The virtual channel over which a GSMP session is established 94 between a controller and the switch it is controlling is called 95 the GSMP control channel. The default VPI and VCI of the GSMP 96 control channel for LLC/SNAP encapsulated GSMP messages on an ATM 97 data link layer is: 99 VPI = 0 100 VCI = 15. 102 3. Ethernet Encapsulation 104 GSMP packets may be encapsulated on an Ethernet data link as 105 illustrated: 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Destination Address | 111 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | | | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 114 | Source Address | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Ethertype (0x88-0C) | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 118 | | 119 ~ GSMP Message ~ 120 | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Sender Instance | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Receiver Instance | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Pad | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Frame Check Sequence | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Destination Address 132 For the SYN message of the adjacency protocol the 133 Destination Address is the broadcast address 134 0xFFFFFFFFFFFF. (Alternatively, it is also valid to 135 configure the node with the unicast 48-bit IEEE MAC 136 address of the destination. In this case the configured 137 unicast Destination Address is used in the SYN message.) 138 For all other messages the Destination Address is the 139 unicast 48- bit IEEE MAC address of the destination. 140 This address may be discovered from the Source Address 141 field of messages received during synchronisation of the 142 adjacency protocol. 144 Source Address 145 For all messages the Source Address is the 48-bit IEEE 146 MAC address of the sender. 148 Ethertype 149 The assigned Ethertype for GSMP is 0x880C. 151 GSMP Message 152 The maximum transmission unit (MTU) of the GSMP Message 153 field is 1492 bytes. 155 Sender Instance 156 The Sender Instance number for the link obtained from 157 the adjacency protocol. This field is already present in 158 the adjacency protocol message. It is appended to all 159 non-adjacency GSMP messages in the Ethernet 160 encapsulation to offer additional protection against the 161 introduction of corrupt state. 163 Receiver Instance 164 The Receiver Instance number is what the sender believes 165 is the current instance number for the link, allocated 166 by the entity at the far end of the link. This field is 167 already present in the adjacency protocol message. It is 168 appended to all non-adjacency GSMP messages in the 169 Ethernet encapsulation to offer additional protection 170 against the introduction of corrupt state. 172 Pad 173 After adjacency has been established the minimum length 174 of the data field of an Ethernet packet is 46 bytes. If 175 necessary, padding should be added such that it meets 176 the minimum Ethernet frame size. This padding should be 177 bytes of zero and it is not considered to be part of 178 the GSMP message. 180 Frame Check Sequence 181 The Frame Check Sequence (FCS) is defined in IEEE 802.3 182 [6] as follows: 183 "A cyclic redundancy check (CRC) is used by the transmit 184 and receive algorithms to generate a CRC value for the 185 FCS field. 186 The frame check sequence (FCS) field contains a 4-byte 187 (32-bit) cyclic redundancy check (CRC) value. 188 This value is computed as a function of the contents of 189 the source address, destination address, length, LLC 190 data and pad (that is, all fields except the preamble, 191 SFD, FCS and extension). 192 The encoding is defined by the following generating 193 polynomial. 194 G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5 195 +x^4+x^2+x^1." 196 The procedure for the CRC calculation can be found in 197 [6]. 199 After the adjacency protocol has achieved synchronisation, for 200 every GSMP message received with an Ethernet encapsulation, the 201 receiver must check the Source Address from the Ethernet MAC 202 header, the Sender Instance, and the Receiver Instance. The 203 incoming GSMP message must be discarded if the Sender Instance and 204 the Source Address do not match the values of Sender Instance and 205 Sender Name stored by the "Update Peer Verifier" operation of the 206 GSMP adjacency protocol. The incoming GSMP message must also be 207 discarded if it arrives over any port other than the port over 208 which the adjacency protocol has achieved synchronisation. In 209 addition, the incoming message must also be discarded if the 210 Receiver Instance field does not match the current value for the 211 Sender Instance of the GSMP adjacency protocol. 213 4. TCP/IP Encapsulation 215 GSMP messages may be transported over an IP network using the TCP 216 encapsulation. TCP provides reliable transport, network flow 217 control, and end-system flow control suitable for networks that 218 may have high loss and variable or unpredictable delay. The GSMP 219 encapsulation in TCP/IP also provides sender authentication using 220 an MD5 digest. 222 For TCP encapsulations of GSMP messages, the controller runs the 223 client code and the switch runs the server code. Upon 224 initialisation, the server is listening on GSMP's TCP port number: 225 6068. The controller establishes a TCP connection with each switch 226 it manages. The switch under control must be a multi-connection 227 server (PORT 6068) to allow creation of multiple control sessions 228 from N GSMP controller instances. Adjacency protocol messages, 229 which are used to synchronise the controller and switch and 230 maintain handshakes, are sent by the controller to the switch 231 after the TCP connection is established. GSMP messages other than 232 adjacency protocol messages may be sent only after the adjacency 233 protocol has achieved synchronisation. The actual GSMP message 234 flow will occur on other ports. 236 4.1 Message Formats 238 GSMP messages are sent over a TCP connection. A GSMP message is 239 processed only after it is entirely received. A four-byte TLV 240 header field is prepended to the GSMP message to provide 241 delineation of GSMP messages within the TCP stream. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type (0x88-0C) | Length | 247 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 ~ GSMP Message ~ 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Type 254 This 2-byte field indicates the type code of the 255 following message. The type code for GSMP messages is 256 0x88-0C (i.e. the same as GSMP's Ethertype). 258 Length: This 2-byte unsigned integer indicates the total length 259 of the GSMP message only. It does not including the 260 4-byte TLV header. 262 4.2 TCP/IP Security consideration 264 Security between the controller and client MUST be provided by IP 265 Security [IPSEC]. In this case, the IPSEC Authentication Header(AH) 266 SHOULD be used for the validation of the connection; additionally 267 IPSEC Encapsulation Security Payload (ESP) MAY be used to provide 268 both validation and secrecy. 270 5. Security Considerations 272 The security of GSMP's TCP/IP control channel has been addressed 273 in Section 4.2. Security over ATM and Ethernet must be provided at 274 the link layer. Discussion of these methods is beyond the scope 275 of this specification. 277 References 279 [1] A. Doria, "General Switch Management Protocol," Internet- 280 Draft draft-ietf-gsmp-07, November 2000. Work in Progress 282 [2] "B-ISDN ATM Layer Specification," International 283 Telecommunication Union, ITU-T Recommendation I.361, Feb. 284 1999. 286 [3] "B-ISDN ATM Adaptation Layer (AAL) Specification," 287 International Telecommunication Union, ITU-T 288 Recommendation I.363, Mar. 1993. 290 [4] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", 291 International Telecommunication Union, ITU-T 292 Recommendation I.363.5, Aug. 1996. 294 [5] Reynolds, J., and J. Postal, "Assigned Numbers", STD 2, RFC 295 1700, October 1994. For the current numbers refer to 296 http://www.isi.edu/in-notes/iana/assignments/port-numbers 298 [6] IEEE Std 802.3, 1998 Edition 299 "Information technology-Telecommunications and information 300 exchange between systems - Local and metropolitan area 301 networks - Specific requirements - Part 3: Carrier sense 302 multiple access with collision detection (CSMA/CD) access 303 method and physical layer specifications" 305 Authors' Addresses 307 Tom Worster 308 Ennovate Networks 309 60 Codman Hill Rd 310 Boxboro MA 01719 USA 311 Tel +1 978-263-2002 312 fsb@thefsb.org 314 Avri Doria 315 Nortel Networks 316 600 Technology Park Drive 317 Billerica MA 01821 USA 318 Tel: +1 401 663 5024 319 avri@nortelnetworks.com 321 Joachim Buerkle 322 Nortel Networks Germany GmbH & Co. KG 323 Hahnstr. 37-39 324 60528 Frankfurt am Main 325 Germany 326 Joachim.Buerkle@nortelnetworks.com