\
GSMP Working Group                     Tom Worster, Ennovate Networks
INTERNET DRAFT                            Avri Doria, Nortel Networks
Standards Track                                  Expires January 2001
July 2000



        GSMP Packet Encapsulations for ATM, Ethernet and TCP

                       <draft-ietf-gsmp-encaps-02.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 Jan 2001              [Page 1]


Internet Draft        GSMP Packet Encapsulations      July 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 Error!
  Reference source not found. 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


Worster, Doria          Expires Jan 2001            [Page 2]


Internet Draft        GSMP Packet Encapsulations      July 2000

  most significant bit. 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, Doria          Expires Jan 2001            [Page 3]


Internet Draft        GSMP Packet Encapsulations      July 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, Doria          Expires Jan 2001            [Page 4]


Internet Draft        GSMP Packet Encapsulations      July 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, Doria          Expires Jan 2001            [Page 5]


Internet Draft        GSMP Packet Encapsulations      July 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 TCCP port
  number: 6068. 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 TCP/IP Security consideration

  Security between the controller and client MUST be provided by IP
  Security [IPSEC]. In this case, the IPSEC Authentication Header(AH)
  SHOULD be used for the validation of the connection; additionally
  IPSEC Encapsulation Security Payload (ESP) MAY be used to provide
  both validation and secrecy.






Worster, Doria          Expires Jan 2001            [Page 6]


Internet Draft        GSMP Packet Encapsulations      July 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]  A. Doria, "General Switch Management Protocol," Internet-
            Draft draft-ietf-gsmp-06, July 2000. Work in Progress

       [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]  http://www.isi.edu/in-notes/iana/assignments/port-numbers




Authors' Addresses

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

     Avri Doria
     Nortel Network
     600 Technology Park Drive
     Billerica MA 01821
     Tel: +1 401 663 5024
     avri@nortelnetworks.com










Worster, Doria          Expires Jan 2001            [Page 7]