RFC 4204 - Link Management Protocol (LMP)(9)

时间:2006-11-01 来源: 作者: 点击:
------------------------------------------------------------------ LMPObjectClassnamespaceandClasstype(C-Type) oCCIDClassname(1) TheCCIDObjectClasstypenamespaceshouldbeallocatedasfollows: pursuanttot
  

   ------------------------------------------------------------------

   LMP Object Class name space and Class type (C-Type)

   o CCID                  Class name (1)

   The CCID Object Class type name space should be allocated as follows:
   pursuant to the policies outlined in [RFC2434], the numbers in the
   range 0-111 are allocated by Standards Action, 112-119 are allocated
   through an Expert Review, and 120-127 are reserved for Private Use.

     - LOCAL_CCID                      (C-Type = 1)
     - REMOTE_CCID                     (C-Type = 2)

   o NODE_ID               Class name (2)

   The NODE ID Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - LOCAL_NODE_ID                   (C-Type = 1)
     - REMOTE_NODE_ID                  (C-Type = 2)

   o LINK_ID               Class name (3)

   The LINK_ID Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - IPv4 LOCAL_LINK_ID              (C-Type = 1)
     - IPv4 REMOTE_LINK_ID             (C-Type = 2)
     - IPv6 LOCAL_LINK_ID              (C-Type = 3)
     - IPv6 REMOTE_LINK_ID             (C-Type = 4)
     - Unnumbered LOCAL_LINK_ID        (C-Type = 5)
     - Unnumbered REMOTE_LINK_ID       (C-Type = 6)

   o INTERFACE_ID          Class name (4)

   The INTERFACE_ID Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - IPv4 LOCAL_INTERFACE_ID         (C-Type = 1)
     - IPv4 REMOTE_INTERFACE_ID        (C-Type = 2)
     - IPv6 LOCAL_INTERFACE_ID         (C-Type = 3)
     - IPv6 REMOTE_INTERFACE_ID        (C-Type = 4)
     - Unnumbered LOCAL_INTERFACE_ID   (C-Type = 5)
     - Unnumbered REMOTE_INTERFACE_ID  (C-Type = 6)

   o MESSAGE_ID            Class name (5)

   The MESSAGE_ID Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - MESSAGE_ID                      (C-Type = 1)
     - MESSAGE_ID_ACK                  (C-Type = 2)

   o CONFIG                Class name (6)

   The CONFIG Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - HELLO_CONFIG                    (C-Type = 1)

   o HELLO                 Class name (7)

   The HELLO Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - HELLO                           (C-Type = 1)

   o BEGIN_VERIFY          Class name (8)

   The BEGIN_VERIFY Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - Type 1                          (C-Type = 1)

   o BEGIN_VERIFY_ACK      Class name (9)

   The BEGIN_VERIFY_ACK Object Class type name space should be allocated
   as follows: pursuant to the policies outlined in [RFC2434], the
   numbers in the range 0-111 are allocated by Standards Action, 112-119
   are allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - Type 1                          (C-Type = 1)

   o VERIFY_ID             Class name (10)

   The VERIFY_ID Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - Type 1                          (C-Type = 1)

   o TE_LINK               Class name (11)

   The TE_LINK Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

     - IPv4 TE_LINK                    (C-Type = 1)
     - IPv6 TE_LINK                    (C-Type = 2)
     - Unnumbered TE_LINK              (C-Type = 3)

   o DATA_LINK             Class name (12)

   The DATA_LINK Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   private Use.

    - IPv4 DATA_LINK                  (C-Type = 1)
    - IPv6 DATA_LINK                  (C-Type = 2)
    - Unnumbered DATA_LINK            (C-Type = 3)

   The DATA_LINK Sub-object Class name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range of 0-127 are allocated by Standards Action, 128-247 are
   allocated through an Expert Review, and 248-255 are reserved for
   private Use.

    - Interface Switching Type        (sub-object Type = 1)
    - Wavelength                      (sub-object Type = 2)

   o CHANNEL_STATUS        Class name (13)

   The CHANNEL_STATUS Object Class type name space should be allocated
   as follows: pursuant to the policies outlined in [RFC2434], the
   numbers in the range 0-111 are allocated by Standards Action, 112-119
   are allocated through an Expert Review, and 120-127 are reserved for
   Private Use.

    - IPv4 INTERFACE_ID               (C-Type = 1)
    - IPv6 INTERFACE_ID               (C-Type = 2)
    - Unnumbered INTERFACE_ID         (C-Type = 3)

   o CHANNEL_STATUS_REQUESTClass name (14)

   The CHANNEL_STATUS_REQUEST Object Class type name space should be
   allocated as follows: pursuant to the policies outlined in [RFC2434],
   the numbers in the range 0-111 are allocated by Standards Action,
   112-119 are allocated through an Expert Review, and 120-127 are
   reserved for Private Use.

    - IPv4 INTERFACE_ID               (C-Type = 1)
    - IPv6 INTERFACE_ID               (C-Type = 2)
    - Unnumbered INTERFACE_ID         (C-Type = 3)

   o ERROR_CODE            Class name (20)

   The ERROR_CODE Object Class type name space should be allocated as
   follows: pursuant to the policies outlined in [RFC2434], the numbers
   in the range 0-111 are allocated by Standards Action, 112-119 are
   allocated through an Expert Review, and 120-127 are reserved for
   private Use.

    - BEGIN_VERIFY_ERROR              (C-Type = 1)
    - LINK_SUMMARY_ERROR              (C-Type = 2)

17.  Acknowledgements

   The authors would like to thank Andre Fredette for his many
   contributions to this document.  We would also like to thank Ayan
   Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay
   Ravuri, and David Drysdale for their insightful comments and
   suggestions.  We would also like to thank John Yu, Suresh Katukam,
   and Greg Bernstein for their helpful suggestions for the in-band
   control channel applicability.

18.  Contributors

   Jonathan P. Lang
   Sonos, Inc.
   223 E. De La Guerra St.
   Santa Barbara, CA 93101

   EMail: jplang@ieee.org

   Krishna Mitra
   Independent Consultant

   EMail: kmitra@earthlink.net

   John Drake
   Calient Networks
   5853 Rue Ferrari
   San Jose, CA 95138

   EMail: jdrake@calient.net

   Kireeti Kompella
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089

   EMail: kireeti@juniper.net

   Yakov Rekhter
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089

   EMail: yakov@juniper.net

   Lou Berger
   Movaz Networks

   EMail: lberger@movaz.com

   Debanjan Saha
   IBM Watson Research Center

   EMail: dsaha@us.ibm.com

   Debashis Basak
   Accelight Networks
   70 Abele Road, Suite 1201
   Bridgeville, PA 15017-3470

   EMail: dbasak@accelight.com

   Hal Sandick
   Shepard M.S.
   2401 Dakota Street
   Durham, NC 27705

   EMail: sandick@nc.rr.com

   Alex Zinin
   Alcatel

   EMail: alex.zinin@alcatel.com

   Bala Rajagopalan
   Intel Corp.
   2111 NE 25th Ave
   Hillsboro, OR 97123

   EMail: bala.rajagopalan@intel.com

   Sankar Ramamoorthi
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089

   EMail: sankarr@juniper.net

Contact Address

   Jonathan P. Lang
   Sonos, Inc.
   829 De La Vina, Suite 220
   Santa Barbara, CA 93101

   EMail: jplang@ieee.org

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容