Movatterモバイル変換

Network Working Group                                           A. DoriaRequest for Comments: 3293                Lulea University of TechnologyCategory: Standards Track                                     J. Buerkle                                                         Nortel Networks                                                              T. Worster                                                               June 2002General Switch Management Protocol (GSMP)Packet Encapsulations for Asynchronous Transfer Mode (ATM),Ethernet and Transmission Control Protocol (TCP)Status of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   This memo specifies the encapsulation of GSMP (General Switch   Management Protocol) packets in ATM (Asynchronous Transfer Mode),   Ethernet and TCP (Transmission Control Protocol).Specification of Requirements   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described inRFC 2119 [7].1. Introduction   GSMP messages are defined in [1] and MAY be encapsulated in several   different protocols for transport.  This memo specifies their   encapsulation in ATM AAL-5, in Ethernet or in TCP.  Other   encapsulations may be defined in future specifications.Doria, et. al.              Standards Track                     [Page 1]

RFC 3293               GSMP Packet Encapsulations              June 20022. ATM Encapsulation   GSMP packets are variable length and for an ATM data link layer they   are encapsulated directly in an AAL-5 CPCS-PDU [3][4] with an   LLC/SNAP header as illustrated:    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-88-0C)                     |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                                                               |   ~                         GSMP Message                          ~   |                                                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                      Pad (0 - 47 bytes)                       |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                                                               |   +             AAL-5 CPCS-PDU Trailer (8 bytes)                  +   |                                                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   (The convention in the documentation of Internet Protocols [5] is to   express numbers in decimal.  Numbers in hexadecimal format are   specified by prefacing them with the characters "0x".  Numbers in   binary format are specified by prefacing them with the characters   "0b".  Data is pictured in "big-endian" order.  That is, fields are   described left to right, with the most significant byte on the left   and the least significant byte on the right.  Whenever a diagram   shows a group of bytes, the order of transmission of those bytes is   the normal order in which they are read in English.  Whenever a byte   represents a numeric quantity the left most bit in the diagram is the   high order or most significant bit.  That is, the bit labelled 0 is   the most significant bit.  Similarly, whenever a multi-byte field   represents a numeric quantity the left most bit of the whole field is   the most significant bit.  When a multi-byte quantity is transmitted,   the most significant byte is transmitted first.  This is the same   coding convention as is used in the ATM layer [2] and AAL-5 [3][4].)   The LLC/SNAP header contains the bytes: 0xAA 0xAA 0x03 0x00 0x00 0x00   0x88 0x0C.  (0x880C is the assigned Ethertype for GSMP.)   The maximum transmission unit (MTU) of the GSMP Message field is 1492   bytes.Doria, et. al.              Standards Track                     [Page 2]

RFC 3293               GSMP Packet Encapsulations              June 2002   The virtual channel over which a GSMP session is established between   a controller and the switch it is controlling is called the GSMP   control channel.  The default VPI and VCI of the GSMP control channel   for LLC/SNAP encapsulated GSMP messages on an ATM data link layer is:      VPI = 0      VCI = 15.   The GSMP control channel MAY be changed using the GSMP MIB.3. Ethernet Encapsulation   GSMP packets MAY be encapsulated on an Ethernet data link as   illustrated:    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                      Destination Address                      |   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                               |                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |   |                         Source Address                        |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Ethertype (0x88-0C)       |                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |   |                                                               |   ~                         GSMP Message                          ~   |                                                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                        Sender Instance                        |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                       Receiver Instance                       |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                              Pad                              |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                       Frame Check Sequence                    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Destination Address      For the SYN message of the adjacency protocol the Destination      Address is the broadcast address 0xFFFFFFFFFFFF.  (Alternatively,      it is also valid to configure the node with the unicast 48-bit      IEEE MAC address of the destination.  In this case the configured      unicast Destination Address is used in the SYN message.)  For all      other messages the Destination Address is the unicast 48-bitDoria, et. al.              Standards Track                     [Page 3]

RFC 3293               GSMP Packet Encapsulations              June 2002      IEEE.  MAC address of the destination.  This address may be      discovered from the Source Address field of messages received      during synchronisation of the adjacency protocol.   Source Address      For all messages, the Source Address is the 48-bit IEEE MAC      address of the sender.   Ethertype      The assigned Ethertype for GSMP is 0x880C.   GSMP Message      The maximum transmission unit (MTU) of the GSMP Message field is      1492 bytes.   Sender Instance      The Sender Instance number for the link obtained from the      adjacency protocol.  This field is already present in the      adjacency protocol message.  It is appended to all non-adjacency      GSMP messages in the Ethernet encapsulation to offer additional      protection against the introduction of corrupt state.   Receiver Instance      The Receiver Instance number is what the sender believes is the      current instance number for the link, allocated by the entity at      the far end of the link.  This field is already present in the      adjacency protocol message.  It is appended to all non-adjacency      GSMP messages in the Ethernet encapsulation to offer additional      protection against the introduction of corrupt state.   Pad      After adjacency has been established the minimum length of the      data field of an Ethernet packet is 46 bytes.  If necessary,      padding should be added such that it meets the minimum Ethernet      frame size.  This padding should be bytes of zero and is not to be      considered part of the GSMP message.   Frame Check Sequence      The Frame Check Sequence (FCS) is defined in IEEE 802.3 [6] as      follows:         Note: This section is included for informational and historical         purposes only.  The normative reference can be found in IEEE         802.3 Standard [6].          "A cyclic redundancy check (CRC) is used by the transmit and         receive algorithms to generate a CRC value for the FCS field.         The frame check sequence (FCS) field contains a 4-byte (32-bit)Doria, et. al.              Standards Track                     [Page 4]

RFC 3293               GSMP Packet Encapsulations              June 2002         cyclic redundancy check (CRC) value.  This value is computed as         a function of the contents of the source address, destination         address, length, LLC data and pad (that is, all fields except         the preamble, SFD, FCS and extension).  The encoding is defined         by the following generating polynomial.         G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^         7+x^5+x^4+x^2+x^1."         The procedure for the CRC calculation can be found in [6].   After the adjacency protocol has achieved synchronisation, for every   GSMP message received with an Ethernet encapsulation, the receiver   must check the Source Address from the Ethernet MAC header, the   Sender Instance, and the Receiver Instance.  The incoming GSMP   message must be discarded if the Sender Instance and the Source   Address do not match the values of the Sender Instance and the Sender   Name stored by the "Update Peer Verifier" operation of the GSMP   adjacency protocol.  The incoming GSMP message must also be discarded   if it arrives over any port other than the port over which the   adjacency protocol has achieved synchronisation.  In addition, the   incoming message must also be discarded if the Receiver Instance   field does not match the current value for the Sender Instance of the   GSMP adjacency protocol.4. TCP/IP Encapsulation   When GSMP messages are transported over an IP network, they MUST be   transported using the TCP encapsulation.  TCP provides reliable   transport, network flow control, and end-system flow control suitable   for networks that may have high loss and variable or unpredictable   delay.   For TCP encapsulations of GSMP messages, the controller runs the   client code and the switch runs the server code.  Upon   initialisation, the server is listening on GSMP's TCP port number:   6068.  The controller establishes a TCP connection with each switch   it manages.  The switch under control MUST be a multi-connection   server (PORT 6068) to allow creation of multiple control sessions   from N GSMP controller instances.  Adjacency protocol messages, which   are used to synchronise the controller and switch and maintain   handshakes, are sent by the controller to the switch after the TCP   connection is established.  GSMP messages other than adjacency   protocol messages MUST NOT be sent until after the adjacency protocol   has achieved synchronisation.  The actual GSMP message flow will   occur on other ports.Doria, et. al.              Standards Track                     [Page 5]

RFC 3293               GSMP Packet Encapsulations              June 20024.1 Message Formats   GSMP messages are sent over a TCP connection.  A GSMP message is   processed only after it is entirely received.  A four-byte TLV header   field is prepended to the GSMP message to provide delineation of GSMP   messages within the TCP stream.    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |        Type (0x88-0C)         |           Length              |   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                                                               |   ~                         GSMP Message                          ~   |                                                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Type      This 2-byte field indicates the type code of the following      message.  The type code for GSMP messages is 0x88-0C (i.e., the      same as GSMP's Ethertype).   Length      This 2-byte unsigned integer indicates the total length of the      GSMP message only.  It does not include the 4-byte TLV header.4.2 TCP/IP Security consideration   When GSMPv3 is implemented for use in IP networks, provisions for   security between the controller and client MUST be available and MUST   be provided by IP Security [IPSEC].  In this case, the IPSEC   Encapsulation Security Payload (ESP) MUST be used to provide both   integrity and confidentiality.5. Security Considerations   The security of GSMP's TCP/IP control channel has been addressed inSection 4.2.  For all uses of GSMP over an IP network it is REQUIRED   that GSMP be run over TCP/IP using the security considerations   discussed inSection 4.2.  Security using ATM and Ethernet   encapsulations MAY be provided at the link layer.  Discussion of   these methods is beyond the scope of this specification.  For secure   operation over any media, the IP encapsulation with IPsec SHOULD be   used.Doria, et. al.              Standards Track                     [Page 6]

RFC 3293               GSMP Packet Encapsulations              June 2002References   [1] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General       Switch Management Protocol (GSMP) V3",RFC 3292, June 2002.   [2] "B-ISDN ATM Layer Specification," International Telecommunication       Union, ITU-T Recommendation I.361, Feb. 1999.   [3] "B-ISDN ATM Adaptation Layer (AAL) Specification," International       Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.   [4] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL",       International Telecommunication Union, ITU-T Recommendation       I.363.5, Aug. 1996.   [5] Reynolds, J., Editor, "Assigned Numbers",RFC 3232, January 2002.   [6] IEEE Std 802.3, 1998 Edition       "Information technology-Telecommunications and information       exchange between systems - Local and metropolitan area networks -       Specific requirements - Part 3: Carrier sense multiple access       with collision detection (CSMA/CD) access method and physical       layer specifications"   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement       Levels",BCP 14,RFC 2119, March 1997.Doria, et. al.              Standards Track                     [Page 7]

RFC 3293               GSMP Packet Encapsulations              June 2002Authors' Addresses   Tom Worster   Phone: +1 617 247 2624   EMail: fsb@thefsb.org   Avri Doria   Div. of Computer Communications   Lulea University of Technology   S-971 87 Lulea   Sweden   Phone: +1 401 663 5024   EMail: avri@acm.com   Joachim Buerkle   Nortel Networks Germany GmbH & Co. KG   Hahnstr. 37-39   60528 Frankfurt am Main   Germany   EMail: Joachim.Buerkle@nortelnetworks.comDoria, et. al.              Standards Track                     [Page 8]

RFC 3293               GSMP Packet Encapsulations              June 2002Full Copyright Statement   Copyright (C) The Internet Society (2002).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Doria, et. al.              Standards Track                     [Page 9]