rfc2997.txt

<VC++网络游戏建摸与实现>源代码


RFC 2997           Specification of Null Service Type      November 2000


   A complete ADSPEC supporting only the Null Service is illustrated
   below:

      31            24 23           16 15            8 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    1 | 0 (a) |    Reserved           |  Msg length -1 (b)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    2 | 1 (c)         |x| Reserved    |           8 (d)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    3 |    4 (e)        |    (f)      |           1 (g)               |
    + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    4 |                    IS hop cnt (32-bit unsigned)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    5 |    6 (h)        |    (i)      |           1 (j)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    6 |   Path b/w estimate  (32-bit IEEE floating point number)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    7 |    8 (k)        |    (l)      |           1 (m)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    8 |        Minimum path latency (32-bit integer)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    9 |   10 (n)        |    (o)      |           1 (p)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10 |        Composed MTU (32-bit unsigned)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   11 |    6 (q)      |x| Reserved    |           0 (r)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Word 1: Message Header:
    (a) - Message header and version number
    (b) - Message length (10 words not including header)

    Words 2-10: Default general characterization parameters
    (c) - Per-Service header, service number 1  (Default General
          Parameters)
    (x) - Global Break bit (NON_IS_HOP general parameter 2)
    (d) - Length of General Parameters data block (8 words)
    (e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general
          parameter)
    (f) - Parameter 4 flag byte
    (g) - Parameter 4 length, 1 word not including header
    (h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general
          parameter)
    (i) - Parameter 6 flag byte
    (j) - Parameter 6 length, 1 word not including header
    (k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general
          parameter)
    (l) - Parameter 8 flag byte



Bernet, et al.              Standards Track                     [Page 7]

RFC 2997           Specification of Null Service Type      November 2000


    (m) - Parameter 8 length, 1 word not including header
    (n) - Parameter ID, parameter 10 (PATH_MTU general parameter)
    (o) - Parameter 10 flag byte
    (p) - Parameter 10 length, 1 word not including header

    Word 11: Null Service parameters

    (q) - Per-Service header, service number 6 (Null)
    (x) - Break bit for Null Service
    (r) - Length (0) of per-service data not including header word.

   Note that the standard rules for parsing ADSPEC service fragments
   ensure that the ADSPEC will not be rejected by legacy network
   elements.  Specifically, these rules state that a network element
   encountering a per-service data header which it does not understand
   should set bit 23 (the break-bit) to indicate that the service is not
   supported and should use the length field from the header to skip
   over the rest of the fragment.

   Also note that it is likely that it will not be possible for hosts or
   network nodes to generate meaningful values for words 5 and/or 7
   (bandwidth estimates and path latency), due to the nature of the
   service.  In this case, the unknown values from [RFC2216] should be
   used.

4.3 SENDER_TSPEC Object Format

   The following Tspec is defined to correspond to the Null Service:

     31            24 23           16 15            8 7
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1 |   6 (a)       |0|  Reserved   |             2 (b)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2 | 128 (c)       |    0 (d)      |             1 (e)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3 | Maximum Packet Size [M] (32-bit integer)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Word 1: Service header
    (a) - Service number 6 (Null Service)
    (b) - Length of per-service data, 2 words not including per-service
          header

    Word 2-3: Parameter
    (c) - Parameter ID, parameter 128 (Null Service TSpec)
    (d) - Parameter 128 flags (none set)
    (e) - Parameter 128 length, 1 words not including parameter header




Bernet, et al.              Standards Track                     [Page 8]

RFC 2997           Specification of Null Service Type      November 2000


   Note that the illustration above does not include the standard RSVP
   SENDER_TSPEC object header, nor does it include the sub-object header
   (which indicates the message format version number and length),
   defined in RFC 2205 and RFC 2210, respectively.

   In the case that only the Null Service is advertised in the ADSPEC,
   the Tspec above would be appended immediately after the SENDER_TSPEC
   object header and sub-object header.  In the case that additional
   service types are advertised, requiring the token bucket specific
   Tspec defined in RFC2210, the Tspec above would be appended following
   the token bucket Tspec, which would in turn follow the object header
   and sub-object header.

4.4 FLOWSPEC Object Format

   The format of an RSVP FLOWSPEC object originating at a receiver
   requesting the Null Service is shown below.  The value of 6 in the
   per-service header (field (c), below) indicates that Null Service is
   being requested.

     31            24 23           16 15            8 7
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1 | 0 (a)         |    reserved   |         3 (b)                 |
   + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2 |   6 (c)       |0|  Reserved   |             2 (d)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3 | 128 (e)       |    0 (f)      |             1 (g)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4 | Maximum Packet Size [M] (32-bit integer)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    (a) - Message format version number (0)
    (b) - Overall length (3 words not including header)
    (c) - Service header, service number 6 (Null)
    (d) - Length of data, 2 words not including per-service header
    (e) - Parameter ID, parameter 128 (Null Service TSpec)
    (f) - Parameter 128 flags (none set)
    (g) - Parameter 128 length, 1 words not including parameter header

4.5 DCLASS Object Format

   DCLASS objects may be included in RESV messages.  For details
   regarding the DCLASS object format, see [dclass].

5. Security Considerations

   The message formatting and usage rules described in this note raise
   no new security issues beyond standard RSVP.



Bernet, et al.              Standards Track                     [Page 9]

RFC 2997           Specification of Null Service Type      November 2000


6. References

   [RFC2205]     Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
                 Jamin, "Resource Reservation Protocol (RSVP) - Version
                 1 Functional Specification", RFC 2205, September 1997.

   [RFC2216]     Shenker, S. and J. Wroclawski, "Network Element QoS
                 Control Service Specification Template", RFC 2216,
                 September 1997.

   [RFC2210]     Wroclawski, J., "The Use of RSVP with IETF Integrated
                 Services", RFC 2210, September 1997.

   [intdiff]     Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang,
                 L., Nichols, K., Speer, M., Braden, B. and B. Davie, "A
                 Framework for Integrated Services Operation over
                 Diffserv Networks", RFC 2998, November 2000.

   [diffarch]    Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
                 and W. Weiss, "An Architecture for Differentiated
                 Services", RFC 2475, December 1998.

   [identity]    Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
                 T., Herzog, S., "Identity Representation for RSVP", RFC
                 2752, January 2000.

   [application] Bernet, Y., "Application and Sub Application Identity
                 Policy Objects for Use with RSVP", RFC 2872, June 2000.

   [dclass]      Bernet, Y., "Format of the RSVP DCLASS Object", RFC
                 2996, November 2000.

7.  Acknowledgments

   We thank Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein,
   Ramesh Pabbati and Sanjay Kaniyar for their comments on this memo.















Bernet, et al.              Standards Track                    [Page 10]

RFC 2997           Specification of Null Service Type      November 2000


8. Authors' Addresses

   Yoram Bernet
   Microsoft
   One Microsoft Way
   Redmond, WA 98052

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


   Andrew Smith
   Allegro Networks
   6399 San Ignacio Ave.
   San Jose, CA 95119, USA

   FAX: [phone]
   Email: [e-mail]


   Bruce Davie
   Cisco Systems
   250 Apollo Drive
   Chelmsford, MA 01824

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
























Bernet, et al.              Standards Track                    [Page 11]

RFC 2997           Specification of Null Service Type      November 2000


9.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Bernet, et al.              Standards Track                    [Page 12]