General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)
RFC 3293

Document Type RFC - Proposed Standard (June 2002; No errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 3293 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Scott Bradner
IESG note Responsible: RFC Editor
Send notices to (None)
Network Working Group                                           A. Doria
Request for Comments: 3293                Lulea University of Technology
Category: Standards Track                                     J. Buerkle
                                                         Nortel Networks
                                                              T. Worster
                                                               June 2002

               General 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 in RFC 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 2002

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][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
Show full document text