idnits 2.17.1 draft-ietf-gsmp-encaps-02.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 240: '...oller and client MUST be provided by I...' RFC 2119 keyword, line 242: '... SHOULD be used for the validation of...' RFC 2119 keyword, line 243: '...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 (January 2001) is 8502 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 241 == Unused Reference: '2' is defined on line 257, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 265, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-06 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GSMP Working Group Tom Worster, Ennovate Networks 2 INTERNET DRAFT Avri Doria, Nortel Networks 3 Standards Track Expires January 2001 4 July 2000 6 GSMP Packet Encapsulations for ATM, Ethernet and TCP 8 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as "work 22 in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo specifies the encapsulation of GSMP packets in ATM, 33 Ethernet and TCP. 35 1. Introduction 37 GSMP packets are defined in [1] and may be encapsulated in several 38 different protocols for transport. This memo specifies their 39 encapsulation in ATM AAL-5, in Ethernet or in TCP. Other 40 encapsulations may be defined in future version of this document 41 or in other documents. 43 2. ATM Encapsulation 45 GSMP packets are variable length and for an ATM data link layer 46 they are encapsulated directly in an AAL-5 CPCS-PDU [3] with an 47 LLC/SNAP header as illustrated: 49 0 1 2 3 50 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 51 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 52 | LLC (0xAA-AA-03) | | 53 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 54 | SNAP (0x00-00-00-88-0C) | 55 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 56 | | 57 ~ GSMP Message ~ 58 | | 59 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60 | Pad (0 - 47 octets) | 61 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 62 | | 63 + AAL-5 CPCS-PDU Trailer (8 octets) + 64 | | 65 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 67 (The convention in the documentation of Internet Protocols Error! 68 Reference source not found. is to express numbers in decimal. 69 Numbers in hexadecimal format are specified by prefacing them with 70 the characters "0x". Numbers in binary format are specified by 71 prefacing them with the characters "0b". Data is pictured in "big- 72 endian" order. That is, fields are described left to right, with 73 the most significant octet on the left and the least significant 74 octet on the right. Whenever a diagram shows a group of octets, 75 the order of transmission of those octets is the normal order in 76 which they are read in English. Whenever an octet represents a 77 numeric quantity the left most bit in the diagram is the high 78 order or most significant bit. That is, the bit labelled 0 is the 79 most significant bit. Similarly, whenever a multi-octet field 80 represents a numeric quantity the left most bit of the whole field 81 is the most significant bit. When a multi-octet quantity is 82 transmitted, the most significant octet is transmitted first. This 83 is the same coding convention as is used in the ATM layer [1] and 84 AAL-5 [3].) 86 The LLC/SNAP header contains the octets: 0xAA 0xAA 0x03 0x00 0x00 87 0x00 0x88 0x0C. (0x880C is the assigned Ethertype for GSMP.) 89 The maximum transmission unit (MTU) of the GSMP Message field is 90 1492 octets. 92 The virtual channel over which a GSMP session is established 93 between a controller and the switch it is controlling is called 94 the GSMP control channel. The default VPI and VCI of the GSMP 95 control channel for LLC/SNAP encapsulated GSMP messages on an ATM 96 data link layer is: 98 VPI = 0 99 VCI = 15. 101 3. Ethernet Encapsulation 103 GSMP packets may be encapsulated on an Ethernet data link as 104 illustrated: 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Destination Address | 110 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 113 | Source Address | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Ethertype (0x88-0C) | | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 117 | | 118 ~ GSMP Message ~ 119 | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Sender Instance | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Receiver Instance | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Pad | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Frame Check Sequence | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Destination Address 131 For the SYN message of the adjacency protocol the 132 Destination Address is the broadcast address 133 0xFFFFFFFFFFFF. (Alternatively, it is also valid to 134 configure the node with the unicast 48-bit IEEE MAC 135 address of the destination. In this case the configured 136 unicast Destination Address is used in the SYN message.) 137 For all other messages the Destination Address is the 138 unicast 48- bit IEEE MAC address of the destination. 139 This address may be discovered from the Source Address 140 field of messages received during synchronisation of the 141 adjacency protocol. 143 Source Address 144 For all messages the Source Address is the 48-bit IEEE 145 MAC address of the sender. 147 Ethertype 148 The assigned Ethertype for GSMP is 0x880C. 150 GSMP Message 151 The maximum transmission unit (MTU) of the GSMP Message 152 field is 1492 octets. 154 Sender Instance 155 The Sender Instance number for the link obtained from 156 the adjacency protocol. This field is already present in 157 the adjacency protocol message. It is appended to all 158 non- adjacency GSMP messages in the Ethernet 159 encapsulation to offer additional protection against the 160 introduction of corrupt state. 162 Receiver Instance 163 The Receiver Instance number is what the sender believes 164 is the current instance number for the link, allocated 165 by the entity at the far end of the link. This field is 166 already present in the adjacency protocol message. It is 167 appended to all non-adjacency GSMP messages in the 168 Ethernet encapsulation to offer additional protection 169 against the introduction of corrupt state. 171 Pad 172 The minimum length of the data field of an Ethernet 173 packet is 46 octets. If necessary, padding should be 174 added such that it meets the minimum Ethernet frame 175 size. This padding should be octets of zero and it is 176 not considered to be part of the GSMP message. 178 After the adjacency protocol has achieved synchronisation, for 179 every GSMP message received with an Ethernet encapsulation, the 180 receiver must check the Source Address from the Ethernet MAC 181 header, the Sender Instance, and the Receiver Instance. The 182 incoming GSMP message must be discarded if the Sender Instance and 183 the Source Address do not match the values of Sender Instance and 184 Sender Name stored by the "Update Peer Verifier" operation of the 185 GSMP adjacency protocol. The incoming GSMP message must also be 186 discarded if it arrives over any port other than the port over 187 which the adjacency protocol has achieved synchronisation. In 188 addition, the incoming message must also be discarded if the 189 Receiver Instance field does not match the current value for the 190 Sender Instance of the GSMP adjacency protocol. 192 4. TCP/IP Encapsulation 194 GSMP messages may be transported over an IP network using the TCP 195 encapsulation. TCP provides reliable transport, network flow 196 control, and end-system flow control suitable for networks that 197 may have high loss and variable or unpredictable delay. The GSMP 198 encapsulation in TCP/IP also provides sender authentication using 199 an MD5 digest. 201 For TCP encapsulations of GSMP messages, the controller runs the 202 client code and the switch runs the server code. Upon 203 initialisation, the server is listening on GSMP's TCCP port 204 number: 6068. The controller establishes a TCP connection with 205 each switch it manages. Adjacency protocol messages, which are 206 used to synchronise the controller and switch and maintain 207 handshakes, are sent by the controller to the switch after the TCP 208 connection is established. GSMP messages other than adjacency 209 protocol messages may be sent only after the adjacency protocol 210 has achieved synchronisation. 212 4.1 Message Formats 214 GSMP messages are sent over a TCP connection. A GSMP message is 215 processed only after it is entirely received. A four-byte TLV 216 header field is prepended to the GSMP message to provide 217 delineation of GSMP messages within the TCP stream. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type (0x60-68) | Length | 223 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | | 225 ~ GSMP Message ~ 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Type 230 This 2-octet field indicates the type code of the 231 following message. The type code for GSMP messages is 232 0x00-0C (i.e. the same as GSMP's Ethertype). 234 Length: This 2-octet unsigned integer indicates the total length 235 of the GSMP message only. It does not including the 4- 236 byte TLV header. 238 4.2 TCP/IP Security consideration 240 Security between the controller and client MUST be provided by IP 241 Security [IPSEC]. In this case, the IPSEC Authentication Header(AH) 242 SHOULD be used for the validation of the connection; additionally 243 IPSEC Encapsulation Security Payload (ESP) MAY be used to provide 244 both validation and secrecy. 246 5. Security Considerations 248 The security of GSMP's TCP/IP control channel has been addressed 249 in Section 4.2. Security over ATM and Ethernet must be provided at 250 the link layer. 252 References 254 [1] A. Doria, "General Switch Management Protocol," Internet- 255 Draft draft-ietf-gsmp-06, July 2000. Work in Progress 257 [2] "B-ISDN ATM Layer Specification," International 258 Telecommunication Union, ITU-T Recommendation I.361, Mar. 259 1993. 261 [3] "B-ISDN ATM Adaptation Layer (AAL) Specification," 262 International Telecommunication Union, ITU-T 263 Recommendation I.363, Mar. 1993. 265 [4] http://www.isi.edu/in-notes/iana/assignments/port-numbers 267 Authors' Addresses 269 Tom Worster 270 Ennovate Networks 271 60 Codman Hill Rd 272 Boxboro MA 01719 USA 273 Tel +1 978-263-2002 274 fsb@thefsb.org 276 Avri Doria 277 Nortel Network 278 600 Technology Park Drive 279 Billerica MA 01821 280 Tel: +1 401 663 5024 281 avri@nortelnetworks.com