idnits 2.17.1 draft-ietf-gsmp-encaps-04.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.) -- The document date (February 2002) is 8105 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 278 == 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: 4 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 August 2001 Nortel Networks 6 Expires February 2002 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 Specification of Requirements 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 35 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 36 "OPTIONAL" in this document are to be interpreted as described in 37 RFC2119 [7]. 39 Abstract 41 This memo specifies the encapsulation of GSMP packets in ATM, 42 Ethernet and TCP. 44 1. Introduction 46 GSMP messages are defined in [1] and MAY be encapsulated in 47 several different protocols for transport. This memo specifies 48 their encapsulation in ATM AAL-5, in Ethernet or in TCP. Other 49 encapsulations may be defined in future specifications. 51 2. ATM Encapsulation 53 GSMP packets are variable length and for an ATM data link layer 54 they are encapsulated directly in an AAL-5 CPCS-PDU [3][4] with an 55 LLC/SNAP header as illustrated: 57 0 1 2 3 58 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 59 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60 | LLC (0xAA-AA-03) | | 61 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 62 | SNAP (0x00-00-00-88-0C) | 63 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 64 | | 65 ~ GSMP Message ~ 66 | | 67 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68 | Pad (0 - 47 bytes) | 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | | 71 + AAL-5 CPCS-PDU Trailer (8 bytes) + 72 | | 73 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 (The convention in the documentation of Internet Protocols [5] is 76 to express numbers in decimal. Numbers in hexadecimal format are 77 specified by prefacing them with the characters "0x". Numbers in 78 binary format are specified by prefacing them with the characters 79 "0b". Data is pictured in "big-endian" order. That is, fields are 80 described left to right, with the most significant byte on the 81 left and the least significant byte on the right. Whenever a 82 diagram shows a group of bytes, the order of transmission of those 83 bytes is the normal order in which they are read in English. 84 Whenever an byte represents a numeric quantity the left most bit 85 in the diagram is the high order or most significant bit. That is, 86 the bit labelled 0 is the most significant bit. Similarly, 87 whenever a multi-byte field represents a numeric quantity the left 88 most bit of the whole field is the most significant bit. When a 89 multi-byte quantity is transmitted, the most significant byte is 90 transmitted first. This is the same coding convention as is used 91 in the ATM layer [2] and AAL-5 [3][4].) 93 The LLC/SNAP header contains the bytes: 0xAA 0xAA 0x03 0x00 0x00 94 0x00 0x88 0x0C. (0x880C is the assigned Ethertype for GSMP.) 96 The maximum transmission unit (MTU) of the GSMP Message field is 97 1492 bytes. 99 The virtual channel over which a GSMP session is established 100 between a controller and the switch it is controlling is called 101 the GSMP control channel. The default VPI and VCI of the GSMP 102 control channel for LLC/SNAP encapsulated GSMP messages on an ATM 103 data link layer is: 105 VPI = 0 106 VCI = 15. 108 The GSMP control channel MAY be changed using the GSMP MIB. 110 3. Ethernet Encapsulation 112 GSMP packets MAY be encapsulated on an Ethernet data link as 113 illustrated: 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Destination Address | 119 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 122 | Source Address | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Ethertype (0x88-0C) | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 126 | | 127 ~ GSMP Message ~ 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Sender Instance | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Receiver Instance | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Pad | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Frame Check Sequence | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Destination Address 140 For the SYN message of the adjacency protocol the 141 Destination Address is the broadcast address 142 0xFFFFFFFFFFFF. (Alternatively, it is also valid to 143 configure the node with the unicast 48-bit IEEE MAC 144 address of the destination. In this case the configured 145 unicast Destination Address is used in the SYN message.) 146 For all other messages the Destination Address is the 147 unicast 48- bit IEEE MAC address of the destination. 148 This address may be discovered from the Source Address 149 field of messages received during synchronisation of the 150 adjacency protocol. 152 Source Address 153 For all messages the Source Address is the 48-bit IEEE 154 MAC address of the sender. 156 Ethertype The assigned Ethertype for GSMP is 0x880C. 157 GSMP Message 158 The maximum transmission unit (MTU) of the GSMP Message 159 field is 1492 bytes. 161 Sender Instance 162 The Sender Instance number for the link obtained from 163 the adjacency protocol. This field is already present in 164 the adjacency protocol message. It is appended to all 165 non-adjacency GSMP messages in the Ethernet 166 encapsulation to offer additional protection against the 167 introduction of corrupt state. 169 Receiver Instance 170 The Receiver Instance number is what the sender believes 171 is the current instance number for the link, allocated 172 by the entity at the far end of the link. This field is 173 already present in the adjacency protocol message. It is 174 appended to all non-adjacency GSMP messages in the 175 Ethernet encapsulation to offer additional protection 176 against the introduction of corrupt state. 178 Pad 179 After adjacency has been established the minimum length 180 of the data field of an Ethernet packet is 46 bytes. If 181 necessary, padding should be added such that it meets 182 the minimum Ethernet frame size. This padding should be 183 bytes of zero and it is not considered to be part of the 184 GSMP message. 186 Frame Check Sequence 187 The Frame Check Sequence (FCS) is defined in IEEE 802.3 188 [6] as follows: 190 Note: This section is included for informational 191 and historical purposes only. The normative 192 reference can be found in IEEE 802.3 Standard [6] 194 "A cyclic redundancy check (CRC) is used by the 195 transmit and receive algorithms to generate a CRC 196 value for the FCS field. 197 The frame check sequence (FCS) field contains a 4- 198 byte (32-bit) cyclic redundancy check (CRC) value. 199 This value is computed as a function of the 200 contents of the source address, destination 201 address, length, LLC data and pad (that is, all 202 fields except the preamble, SFD, FCS and 203 extension). 204 The encoding is defined by the following generating 205 polynomial. 206 G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^ 207 7+x^5+x^4+x^2+x^1." 208 The procedure for the CRC calculation can be found 209 in [6]. 211 After the adjacency protocol has achieved synchronisation, for 212 every GSMP message received with an Ethernet encapsulation, the 213 receiver must check the Source Address from the Ethernet MAC 214 header, the Sender Instance, and the Receiver Instance. The 215 incoming GSMP message must be discarded if the Sender Instance and 216 the Source Address do not match the values of Sender Instance and 217 Sender Name stored by the "Update Peer Verifier" operation of the 218 GSMP adjacency protocol. The incoming GSMP message must also be 219 discarded if it arrives over any port other than the port over 220 which the adjacency protocol has achieved synchronisation. In 221 addition, the incoming message must also be discarded if the 222 Receiver Instance field does not match the current value for the 223 Sender Instance of the GSMP adjacency protocol. 225 4. TCP/IP Encapsulation 227 When GSMP messages are transported over an IP network, they MUST 228 be transported using the TCP encapsulation. TCP provides reliable 229 transport, network flow control, and end-system flow control 230 suitable for networks that may have high loss and variable or 231 unpredictable delay. The GSMP encapsulation in TCP/IP also 232 provides sender authentication using an MD5 digest. 234 For TCP encapsulations of GSMP messages, the controller runs the 235 client code and the switch runs the server code. Upon 236 initialisation, the server is listening on GSMP's TCP port number: 237 6068. The controller establishes a TCP connection with each switch 238 it manages. The switch under control MUST be a multi-connection 239 server (PORT 6068) to allow creation of multiple control sessions 240 from N GSMP controller instances. Adjacency protocol messages, 241 which are used to synchronise the controller and switch and 242 maintain handshakes, are sent by the controller to the switch 243 after the TCP connection is established. GSMP messages other than 244 adjacency protocol messages MUST NOT be sent until after the 245 adjacency protocol has achieved synchronisation. The actual GSMP 246 message flow will occur on other ports. 248 4.1 Message Formats 250 GSMP messages are sent over a TCP connection. A GSMP message is 251 processed only after it is entirely received. A four-byte TLV 252 header field is prepended to the GSMP message to provide 253 delineation of GSMP messages within the TCP stream. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type (0x88-0C) | Length | 259 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 ~ GSMP Message ~ 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Type 266 This 2-byte field indicates the type code of the 267 following message. The type code for GSMP messages is 268 0x88-0C (i.e. the same as GSMP's Ethertype). 270 Length: This 2-byte unsigned integer indicates the total length 271 of the GSMP message only. It does not including the 4- 272 byte TLV header. 274 4.2 TCP/IP Security consideration 276 When GSMPv3 is implemented for use in IP networks, provisions for 277 security between the controller and client MUST be available and 278 MUST be provided by IP Security [IPSEC]. In this case, the IPSEC 279 Authentication Header(AH) SHOULD be used for the validation of the 280 connection; additionally IPSEC Encapsulation Security Payload (ESP) 281 MAY be used to provide both validation and secrecy. 283 5. Security Considerations 285 The security of GSMP's TCP/IP control channel has been addressed 286 in Section 4.2. For all uses of GSMP over an IP network it is 287 REQUIRED that GSMP be run over TCP/IP using the security 288 considerations discussed in Section 4.2. Security using ATM and 289 Ethernet encapsulations MAY be provided at the link layer. 290 Discussion of these methods is beyond the scope of this 291 specification. 293 References 295 [1] A. Doria, "General Switch Management Protocol," Internet- 296 Draft draft-ietf-gsmp-07, November 2000. Work in Progress 298 [2] "B-ISDN ATM Layer Specification," International 299 Telecommunication Union, ITU-T Recommendation I.361, Feb. 300 1999. 302 [3] "B-ISDN ATM Adaptation Layer (AAL) Specification," 303 International Telecommunication Union, ITU-T 304 Recommendation I.363, Mar. 1993. 306 [4] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", 307 International Telecommunication Union, ITU-T 308 Recommendation I.363.5, Aug. 1996. 310 [5] Reynolds, J., and J. Postal, "Assigned Numbers", STD 2, RFC 311 1700, October 1994. For the current numbers refer to 312 http://www.iana.org/in-notes/assignments/port-numbers 314 [6] IEEE Std 802.3, 1998 Edition 315 "Information technology-Telecommunications and information 316 exchange between systems - Local and metropolitan area 317 networks - Specific requirements - Part 3: Carrier sense 318 multiple access with collision detection 319 (CSMA/CD) access method and physical layer specifications" 321 [7] S. Bradner, "Key words for use in RFCs to Indicate 322 Requirement Levels", RFC 2119. BCP 14, March 1997. 324 Authors' Addresses 326 Tom Worster 327 Ennovate Networks 328 60 Codman Hill Rd 329 Boxboro MA 01719 USA 330 Tel +1 978-263-2002 331 fsb@thefsb.org 333 Avri Doria 334 Nortel Networks 335 600 Technology Park Drive 336 Billerica MA 01821 USA 337 Tel: +1 401 663 5024 338 avri@nortelnetworks.com 340 Joachim Buerkle 341 Nortel Networks Germany GmbH & Co. KG 342 Hahnstr. 37-39 343 60528 Frankfurt am Main 344 Germany 345 Joachim.Buerkle@nortelnetworks.com