As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group A.
Request for Comments: 3293 Lulea University of
Category: Standards Track J.
Nortel
T.
June 2002
General Switch Management Protocol (GSMP
Packet Encapsulations for Asynchronous Transfer Mode (ATM),
Ethernet and Transmission Control Protocol (TCP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This memo specifies the encapsulation of GSMP (General
Management Protocol) packets in ATM (Asynchronous Transfer Mode),
Ethernet and TCP (Transmission Control Protocol).
Specification of
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [7].
1.
GSMP messages are defined in [1] and MAY be encapsulated in
different protocols for transport. This memo specifies
encapsulation in ATM AAL-5, in Ethernet or in TCP.
encapsulations may be defined in future specifications
Doria, et. al. Standards Track [Page 1]
RFC 3293 GSMP Packet Encapsulations June 2002
2. ATM
GSMP packets are variable length and for an ATM data link layer
are encapsulated directly in an AAL-5 CPCS-PDU [3][4] with
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
express numbers in decimal. Numbers in hexadecimal format
specified by prefacing them with the characters "0x". Numbers
binary format are specified by prefacing them with the
"0b". Data is pictured in "big-endian" order. That is, fields
described left to right, with the most significant byte on the
and the least significant byte on the right. Whenever a
shows a group of bytes, the order of transmission of those bytes
the normal order in which they are read in English. Whenever a
represents a numeric quantity the left most bit in the diagram is
high order or most significant bit. That is, the bit labelled 0
the most significant bit. Similarly, whenever a multi-byte
represents a numeric quantity the left most bit of the whole field
the most significant bit. When a multi-byte quantity is transmitted
the most significant byte is transmitted first. This is the
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
a controller and the switch it is controlling is called the
control channel. The default VPI and VCI of the GSMP control
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
GSMP packets MAY be encapsulated on an Ethernet data link
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
For the SYN message of the adjacency protocol the
Address is the broadcast address 0xFFFFFFFFFFFF. (Alternatively
it is also valid to configure the node with the unicast 48-
IEEE MAC address of the destination. In this case the
unicast Destination Address is used in the SYN message.) For
other messages the Destination Address is the unicast 48-
Doria, et. al. Standards Track [Page 3]
RFC 3293 GSMP Packet Encapsulations June 2002
IEEE. MAC address of the destination. This address may
discovered from the Source Address field of messages
during synchronisation of the adjacency protocol
Source
For all messages, the Source Address is the 48-bit IEEE
address of the sender
The assigned Ethertype for GSMP is 0x880C
GSMP
The maximum transmission unit (MTU) of the GSMP Message field
1492 bytes
Sender
The Sender Instance number for the link obtained from
adjacency protocol. This field is already present in
adjacency protocol message. It is appended to all non-
GSMP messages in the Ethernet encapsulation to offer
protection against the introduction of corrupt state
Receiver
The Receiver Instance number is what the sender believes is
current instance number for the link, allocated by the entity
the far end of the link. This field is already present in
adjacency protocol message. It is appended to all non-
GSMP messages in the Ethernet encapsulation to offer
protection against the introduction of corrupt state
After adjacency has been established the minimum length of
data field of an Ethernet packet is 46 bytes. If necessary
padding should be added such that it meets the minimum
frame size. This padding should be bytes of zero and is not to
considered part of the GSMP message
Frame Check
The Frame Check Sequence (FCS) is defined in IEEE 802.3 [6]
follows
Note: This section is included for informational and
purposes only. The normative reference can be found in
802.3 Standard [6].
"A cyclic redundancy check (CRC) is used by the transmit
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
a function of the contents of the source address,
address, length, LLC data and pad (that is, all fields
the preamble, SFD, FCS and extension). The encoding is
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
GSMP message received with an Ethernet encapsulation, the
must check the Source Address from the Ethernet MAC header,
Sender Instance, and the Receiver Instance. The incoming
message must be discarded if the Sender Instance and the
Address do not match the values of the Sender Instance and the
Name stored by the "Update Peer Verifier" operation of the
adjacency protocol. The incoming GSMP message must also be
if it arrives over any port other than the port over which
adjacency protocol has achieved synchronisation. In addition,
incoming message must also be discarded if the Receiver
field does not match the current value for the Sender Instance of
GSMP adjacency protocol
4. TCP/IP
When GSMP messages are transported over an IP network, they MUST
transported using the TCP encapsulation. TCP provides
transport, network flow control, and end-system flow control
for networks that may have high loss and variable or
delay
For TCP encapsulations of GSMP messages, the controller runs
client code and the switch runs the server code.
initialisation, the server is listening on GSMP's TCP port number
6068. The controller establishes a TCP connection with each
it manages. The switch under control MUST be a multi-
server (PORT 6068) to allow creation of multiple control
from N GSMP controller instances. Adjacency protocol messages,
are used to synchronise the controller and switch and
handshakes, are sent by the controller to the switch after the
connection is established. GSMP messages other than
protocol messages MUST NOT be sent until after the adjacency
has achieved synchronisation. The actual GSMP message flow
occur on other ports
Doria, et. al. Standards Track [Page 5]
RFC 3293 GSMP Packet Encapsulations June 2002
4.1 Message
GSMP messages are sent over a TCP connection. A GSMP message
processed only after it is entirely received. A four-byte TLV
field is prepended to the GSMP message to provide delineation of
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This 2-byte field indicates the type code of the
message. The type code for GSMP messages is 0x88-0C (i.e.,
same as GSMP's Ethertype).
This 2-byte unsigned integer indicates the total length of
GSMP message only. It does not include the 4-byte TLV header
4.2 TCP/IP Security
When GSMPv3 is implemented for use in IP networks, provisions
security between the controller and client MUST be available and
be provided by IP Security [IPSEC]. In this case, the
Encapsulation Security Payload (ESP) MUST be used to provide
integrity and confidentiality
5. Security
The security of GSMP's TCP/IP control channel has been addressed
Section 4.2. For all uses of GSMP over an IP network it is
that GSMP be run over TCP/IP using the security
discussed in Section 4.2. Security using ATM and
encapsulations MAY be provided at the link layer. Discussion
these methods is beyond the scope of this specification. For
operation over any media, the IP encapsulation with IPsec SHOULD
used
Doria, et. al. Standards Track [Page 6]
RFC 3293 GSMP Packet Encapsulations June 2002
[1] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "
Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
[2] "B-ISDN ATM Layer Specification," International
Union, ITU-T Recommendation I.361, Feb. 1999.
[3] "B-ISDN ATM Adaptation Layer (AAL) Specification,"
Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.
[4] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL",
International Telecommunication Union, ITU-T
I.363.5, Aug. 1996.
[5] Reynolds, J., Editor, "Assigned Numbers", RFC 3232, January 2002.
[6] IEEE Std 802.3, 1998
"Information technology-Telecommunications and
exchange between systems - Local and metropolitan area networks -
Specific requirements - Part 3: Carrier sense multiple
with collision detection (CSMA/CD) access method and
layer specifications
[7] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
Doria, et. al. Standards Track [Page 7]
RFC 3293 GSMP Packet Encapsulations June 2002
Authors'
Tom
Phone: +1 617 247 2624
EMail: fsb@thefsb.
Avri
Div. of Computer
Lulea University of
S-971 87
Phone: +1 401 663 5024
EMail: avri@acm.
Joachim
Nortel Networks Germany GmbH & Co.
Hahnstr. 37-39
60528 Frankfurt am
EMail: Joachim.Buerkle@nortelnetworks.
Doria, et. al. Standards Track [Page 8]
RFC 3293 GSMP Packet Encapsulations June 2002
Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Doria, et. al. Standards Track [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
