doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc3293.txt b/doc/rfc/rfc3293.txt
new file mode 100644
index 0000000..6c8d8f9
--- /dev/null
+++ b/doc/rfc/rfc3293.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+   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 Encapsulation
+
+   GSMP packets MAY be encapsulated on an Ethernet data link 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      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
+
+
+
+
+
+Doria, et. al.              Standards Track                     [Page 3]
+
+RFC 3293               GSMP Packet Encapsulations              June 2002
+
+
+      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 bytes.
+
+   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
+      After adjacency has been established the minimum length of the
+      data field of an Ethernet packet is 46 bytes.  If necessary,
+      padding should be added such that it meets the minimum Ethernet
+      frame size.  This padding should be bytes of zero and is not to be
+      considered part of the GSMP message.
+
+   Frame Check Sequence
+      The Frame Check Sequence (FCS) is defined in IEEE 802.3 [6] as
+      follows:
+
+         Note: This section is included for informational and historical
+         purposes only.  The normative reference can be found in IEEE
+         802.3 Standard [6].
+
+          "A cyclic redundancy check (CRC) is used by the transmit and
+         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 as
+         a function of the contents of the source address, destination
+         address, length, LLC data and pad (that is, all fields except
+         the preamble, SFD, FCS and extension).  The encoding is defined
+         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 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 the Sender Instance and the 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
+
+   When GSMP messages are transported over an IP network, they MUST be
+   transported 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.
+
+   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 TCP port number:
+   6068.  The controller establishes a TCP connection with each switch
+   it manages.  The switch under control MUST be a multi-connection
+   server (PORT 6068) to allow creation of multiple control sessions
+   from N GSMP controller instances.  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 MUST NOT be sent until after the adjacency protocol
+   has achieved synchronisation.  The actual GSMP message flow will
+   occur on other ports.
+
+
+
+
+
+Doria, et. al.              Standards Track                     [Page 5]
+
+RFC 3293               GSMP Packet Encapsulations              June 2002
+
+
+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 (0x88-0C)         |           Length              |
+   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                         GSMP Message                          ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+      This 2-byte field indicates the type code of the following
+      message.  The type code for GSMP messages is 0x88-0C (i.e., the
+      same as GSMP's Ethertype).
+
+   Length
+      This 2-byte unsigned integer indicates the total length of the
+      GSMP message only.  It does not include the 4-byte TLV header.
+
+4.2 TCP/IP Security consideration
+
+   When GSMPv3 is implemented for use in IP networks, provisions for
+   security between the controller and client MUST be available and MUST
+   be provided by IP Security [IPSEC].  In this case, the IPSEC
+   Encapsulation Security Payload (ESP) MUST be used to provide both
+   integrity and confidentiality.
+
+5. Security Considerations
+
+   The security of GSMP's TCP/IP control channel has been addressed in
+   Section 4.2.  For all uses of GSMP over an IP network it is REQUIRED
+   that GSMP be run over TCP/IP using the security considerations
+   discussed in Section 4.2.  Security using ATM and Ethernet
+   encapsulations MAY be provided at the link layer.  Discussion of
+   these methods is beyond the scope of this specification.  For secure
+   operation over any media, the IP encapsulation with IPsec SHOULD be
+   used.
+
+
+
+
+
+
+
+Doria, et. al.              Standards Track                     [Page 6]
+
+RFC 3293               GSMP Packet Encapsulations              June 2002
+
+
+References
+
+   [1] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General
+       Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
+
+   [2] "B-ISDN ATM Layer Specification," International Telecommunication
+       Union, ITU-T Recommendation I.361, Feb. 1999.
+
+   [3] "B-ISDN ATM Adaptation Layer (AAL) Specification," International
+       Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.
+
+   [4] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL",
+       International Telecommunication Union, ITU-T Recommendation
+       I.363.5, Aug. 1996.
+
+   [5] Reynolds, J., Editor, "Assigned Numbers", RFC 3232, January 2002.
+
+   [6] IEEE Std 802.3, 1998 Edition
+       "Information technology-Telecommunications and information
+       exchange between systems - Local and metropolitan area networks -
+       Specific requirements - Part 3: Carrier sense multiple access
+       with collision detection (CSMA/CD) access method and physical
+       layer specifications"
+
+   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Doria, et. al.              Standards Track                     [Page 7]
+
+RFC 3293               GSMP Packet Encapsulations              June 2002
+
+
+Authors' Addresses
+
+   Tom Worster
+
+   Phone: +1 617 247 2624
+   EMail: fsb@thefsb.org
+
+
+   Avri Doria
+   Div. of Computer Communications
+   Lulea University of Technology
+   S-971 87 Lulea
+   Sweden
+
+   Phone: +1 401 663 5024
+   EMail: avri@acm.com
+
+
+   Joachim Buerkle
+   Nortel Networks Germany GmbH & Co. KG
+   Hahnstr. 37-39
+   60528 Frankfurt am Main
+   Germany
+
+   EMail: Joachim.Buerkle@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Doria, et. al.              Standards Track                     [Page 8]
+
+RFC 3293               GSMP Packet Encapsulations              June 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Doria, et. al.              Standards Track                     [Page 9]
+