rfc3293 - Network Working Group A Doria Request for...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
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]
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
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
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 09/13/2009 for the course EE 6345 taught by Professor Cantrell during the Spring '09 term at University of Texas at Dallas, Richardson.

Page1 / 10

rfc3293 - Network Working Group A Doria Request for...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online