rfc3293.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 508 行 · 第 1/2 页

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: [phone]
   EMail: [e-mail]


   Avri Doria
   Div. of Computer Communications
   Lulea University of Technology
   S-971 87 Lulea
   Sweden

   Phone: [phone]
   EMail: [e-mail]


   Joachim Buerkle
   Nortel Networks Germany GmbH & Co. KG
   Hahnstr. 37-39
   60528 Frankfurt am Main
   Germany

   EMail: [e-mail]


























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]