Internet Draft
GSMP Working Group                      Tom Worster, Ennovate Networks
INTERNET DRAFT                                       Avri Doria, Nokia
Standards Track                                   Expires October 2000



            GSMP Packet Encapsulations for ATM, Ethernet and TCP

                      <draft-ietf-gsmp-encaps-01.txt>



   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as "work
   in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This memo specifies the encapsulation of GSMP packets in ATM,
   Ethernet and TCP.








Worster                 Expires June 20th 2000            [Page 1]



Internet Draft        GSMP Packet Encapsulations         Jan 2000





1.  Introduction

   GSMP packets 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 version of this document
   or in other documents.


2.  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] 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 octets)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +            AAL-5 CPCS-PDU Trailer (8 octets)                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   (The convention in the documentation of Internet Protocols [4] 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 octet on the
   left and the least significant octet on the right. Whenever a
   diagram shows a group of octets, the order of transmission of
   those octets is the normal order in which they are read in
   English. Whenever an octet 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.


Worster, et. al.          Expires June 20th 1999            [Page 2]



Internet Draft        GSMP Packet Encapsulations         Jan 2000

   Similarly, whenever a multi-octet field represents a numeric
   quantity the left most bit of the whole field is the most
   significant bit. When a multi-octet quantity is transmitted, the
   most significant octet is transmitted first. This is the same
   coding convention as is used in the ATM layer [1] and AAL-5 [3].)

   The LLC/SNAP header contains the octets: 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 octets.

   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.


3.  Ethernet Encapsulation

   GSMP packets may be encapsulated on an Ethernet data link as
   illustrated:






















Worster, et. al.          Expires June 20th 1999            [Page 3]



Internet Draft        GSMP Packet Encapsulations         Jan 2000


    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- bit 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 octets.



Worster, et. al.          Expires June 20th 1999            [Page 4]



Internet Draft        GSMP Packet Encapsulations         Jan 2000

   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
             The minimum length of the data field of an Ethernet
             packet is 46 octets. If necessary, padding should be
             added such that it meets the minimum Ethernet frame
             size. This padding should be octets of zero and it is
             not considered to be part of the GSMP message.

   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 Sender Instance and
   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

   GSMP messages may be transported over an IP network 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. The GSMP
   encapsulation in TCP/IP also provides sender authentication using
   an MD5 digest.




Worster, et. al.          Expires June 20th 1999            [Page 5]



Internet Draft        GSMP Packet Encapsulations         Jan 2000

   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 (proposed) well
   known port number. The controller establishes a TCP connection
   with each switch it manages. 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 may be sent only after the adjacency protocol
   has achieved synchronisation.

4.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 (0x60-68)         |           Length              |
   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         GSMP Message                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
              This 2-octet field indicates the type code of the
              following message. The type code for GSMP messages is
              0x00-0C (i.e. the same as GSMP's Ethertype).

   Length:
              This 2-octet unsigned integer indicates the total length
              of the GSMP message only. It does not including the 4-
              byte TLV header.

4.2  Security consideration

   To ensure the authenticity and security of GSMP messages which are
   transported through an IP network, standard security measures as
   defined by IP-Sec (RFC 2401) [5] MUST be used.








Worster, et. al.          Expires June 20th 1999            [Page 6]



Internet Draft        GSMP Packet Encapsulations         Jan 2000

5.  Security Considerations

   The security of GSMP's TCP/IP control channel has been addressed
   in Section 4.2. Security over ATM and Ethernet must be provided at
   the link layer.


References

     [1]  T. Worster, "General Switch Management Protocol,"
              Internet-Draft draft-ietf-gsmp-03, Jan 2000.

     [2]  "B-ISDN ATM Layer Specification," International
              Telecommunication Union, ITU-T Recommendation I.361, Mar.
              1993.

     [3]  "B-ISDN ATM Adaptation Layer (AAL) Specification,"
              International Telecommunication Union, ITU-T
              Recommendation I.363, Mar. 1993.

     [4]  Reynolds, J., and J. Postel, "Assigned Numbers," STD 2,
              RFC 1700, October 1994.

     [5]  IP Sec


Authors' Addresses

   Tom Worster
   Ennovate Networks
   60 Codman Hill Rd
   Boxboro MA 01719 USA
   Tel +1 978-263-2002
   fsb@thefsb.org

   Avri Doria
   Nokia
   5 Wayside Rd
   Burlington MA 01803
   Tel: +1 993 4645
   avri.doria@nokia.com









Worster, et. al.          Expires June 20th 1999            [Page 7]