RFC 4220 - Traffic Engineering Link Management Information B

时间:2006-11-01 来源: 作者: 点击:
NetworkWorkingGroupM.Dubuc RequestforComments:4220Consultant Category:StandardsTrackT.Nadeau CiscoSystems J.Lang Sonos,Inc. November2005 TrafficEngineeringLinkManagementInformationBase StatusofThisMemo ThisdocumentspecifiesanInternetstandardstrackpro
  Network Working Group                                           M. Dubuc
Request for Comments: 4220                                    Consultant
Category: Standards Track                                      T. Nadeau
                                                                         Cisco Systems
                                                                                    J. Lang
                                                                              Sonos, Inc.
                                                                       November 2005

          Traffic Engineering Link Management Information Base

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 (2005).

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for modeling TE links as
   described in the Link Bundling in MPLS Traffic Engineering (TE)
   document.

Table of Contents

   1. The Internet-Standard Management Framework ......................2
   2. Introduction ....................................................3
   3. Terminology .....................................................3
   4. Feature Checklist ...............................................4
   5. Outline .........................................................4
   6. Brief Description of MIB Objects ................................4
      6.1. teLinkTable ................................................4
      6.2. teLinkDescriptorTable ......................................4
      6.3. teLinkSrlgTable ............................................5
      6.4. teLinkBandwidthTable .......................................5
      6.5. componentLinkTable .........................................5
      6.6. componentLinkDescriptorTable ...............................5
      6.7. componentLinkBandwidthTable ................................5
   7. Example of Bundled Link Setup ...................................5
   8. Application of the Interfaces Group to TE Links .................9
      8.1. Support of the TE Link Layer by ifTable ....................9
      8.2. Using ifStackTable ........................................11
      8.3. Applicability of ifRcvAddressTable ........................13
   9. TE Link MIB Module Definitions .................................13
   10. Security Considerations .......................................50
   11. Contributors ..................................................51
   12. Acknowledgements ..............................................51
   13. IANA Considerations ...........................................51
       13.1. IANA Considerations for the TE-LINK-STD-MIB .............51
   14. References ....................................................51
       14.1. Normative References ....................................51
       14.2. Informative References ..................................52

1.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

2.  Introduction

   OSPF [RFC3630], Generalized MPLS (GMPLS) [RFC3471], and the Link
   Management Protocol (LMP) [RFC4204] use the concept of traffic
   engineering (TE) links to abstract link properties.  The effect of
   this approach is a reduction in the amount of routing information
   exchanged in the network, which improves routing scalability.  In
   addition, the use of TE links allows the implementation of new
   capabilities such as link protection.

   In this document, we present a MIB module that can be used to manage
   TE links and their extension, the bundled link.  This MIB module
   enables both the configuration and the performance monitoring of TE
   links and the bundled link.

   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 [RFC2119].

3.  Terminology

   This document uses terminology from the documents describing link
   bundling [RFC4201] and GMPLS [RFC3945].

   The link bundling feature is designed to aggregate one or more
   similar entities between a node pair into a bundled link [RFC4201].
   In RFC 4201, those entities are referred to as TE links.  A TE link
   is a subinterface capable of carrying MPLS traffic engineered
   traffic.  A TE Link may be comprised of only one underlying component
   link.  In cases where more than one component links are to be
   combined, multiple component links should be created with differing
   priorities to indicate hot-standby or parallel utilization.

   A bundled link is another kind of Traffic Engineering (TE) link (see
   [RFC4203]).  A link bundle is a subinterface that binds the traffic
   of a group of one or more TE links.  There should be more than one TE
   Link in a link bundle, but this is not a requirement.  Furthermore,
   if there are more than one TE links in a link bundle at some time,
   and at some point later, all but one of the links are deleted, the
   agent may choose to either delete the link bundle, or it may choose
   to leave it intact.  Traffic counters on a link bundle are cumulative
   for all subinterfaces that it binds together.

4.  Feature Checklist

   The TE Link MIB module (TE-LINK-STD-MIB) is designed to satisfy the
   following requirements and constraints:

   -  The MIB module supports the management of TE links, including
      bundled links.

   -  Support is provided for configuration of traffic engineering
      parameters associated with TE links.

   -  The MIB module is used to monitor the priority-based component
      link and TE link bandwidth values.

5.  Outline

   Configuring bundled links involves the following steps:

   -  Creating a bundled link.

   -  Creating TE links.

   -  Optionally specifying the shared risk link groups associated with
      the TE links.

   -  Configuring the component links including the bandwidth parameters
      and associating the component links with the appropriate TE link.

   -  Associating the TE links with the appropriate bundled link.

6.  Brief Description of MIB Objects

   Sections 6.1 - 6.4 describe objects pertaining to TE links while
   Sections 6.5 - 6.7 describe objects pertaining to component links.
   The MIB objects were derived from the link bundling document
   [RFC4201].

6.1.  teLinkTable

   This table represents the TE links, including bundled links, and
   their generic traffic engineering parameters.

6.2.  teLinkDescriptorTable

   This table represents the TE link interface switching capability
   descriptors.

6.3.  teLinkSrlgTable

   This table represents the shared risk link groups (SRLGs) associated
   with TE links.

6.4.  teLinkBandwidthTable

   This table specifies the priority-based bandwidth traffic engineering
   parameters associated with TE links.

6.5.  componentLinkTable

   This table enumerates the component links and their generic traffic
   engineering parameters.

6.6.  componentLinkDescriptorTable

   This table enumerates the interface switching capability descriptors
   that each component link supports.

6.7.  componentLinkBandwidthTable

   The component link bandwidth table specifies the priority-based
   bandwidth values associated with the component links.

   Component links that belong to the same TE link must be compatible.
   If these two tables are managed independently, mechanisms should be
   put in place to ensure consistency between the two tables.  TE links
   that form a bundled link must have compatible traffic engineering
   parameters (resource class, link metric, and protection type).

   The link descriptors of the teLinkDescriptorTable can be derived from
   the link descriptors of the componentLinkDescrTable.

   Some of the bandwidth parameters of the teLinkTable,
   teLinkDescriptorTable, teLinkBandwidthTable are derived from the
   bandwidth parameters of the componentLinkTable,
   componentLinkDescriptorTable, and componentLinkBandwidthTable
   (maximum reservable bandwidth, minimum LSP bandwidth, maximum LSP
   bandwidth at specified priority, and unreserved bandwidth).

7.  Example of Bundled Link Setup

   In this section, we provide a brief example of using the MIB objects
   described in section 10 to set up a bundled link.  While this example
   is not meant to illustrate every nuance of the MIB module, it is
   intended as an aid to understanding some of the key concepts.  It is
   meant to be read after going through the MIB module itself.  Section

   8.2 provides more details on the use of the ifStackTable to establish
   relationships between bundled links, TE links, and component links.

   Suppose that one would like to manually create a bundled link out of
   two 1:1 TE links, as depicted in the figure in Section 8.2.  Assume
   that the bundled link is associated with SRLGs 10 and 50.  Finally,
   let the component links be port entity interfaces (lambdas).  The
   following example illustrates which rows and corresponding objects
   might be created to accomplish this.

   First, a bundled link entry is created.  An ifEntry with the same
   ifIndex and with ifType teLink needs to be created beforehand.

      In teLinkTable:
      {
         ifIndex                        = 2,
         teLinkAddressType              = unknown(0),
         teLinkLocalIpAddr              = ’’H,
         teLinkRemoteIpAddr             = ’’H,
         teLinkMetric                   = 5,
         teLinkProtectionType           = dedicated1For1(4),
         teLinkWorkingPriority          = 7,
         teLinkResourceClass            = 3,
         teLinkIncomingIfId             = 0,
         teLinkOutgoingIfId             = 2,
         teLinkRowStatus                = createAndGo(4),
         teLinkStorageType              = nonVolatile(3)
      }

      In ifStackTable:
      {
         ifStackHigherLayer             = 0,
         ifStackLowerLayer              = 2,
         ifStackStatus                  = createAndGo(4)
      }

   Next, the two TE links are created.

      In teLinkTable:
      {
         ifIndex                        = 3,
         teLinkAddressType              = unknown(0),
         teLinkLocalIpAddr              = ’’H,
         teLinkRemoteIpAddr             = ’’H,
         teLinkMetric                   = 5,
         teLinkProtectionType           = unprotected(2),
         teLinkWorkingPriority          = 7,
         teLinkResourceClass            = 3,

         teLinkIncomingIfId             = 0,
         teLinkOutgoingIfId             = 3,
         teLinkRowStatus                = createAndGo(4),
         teLinkStorageType              = nonVolatile(3)
      }

      In ifStackTable:
      {
         ifStackHigherLayer             = 2,
         ifStackLowerLayer              = 3,
         ifStackStatus                  = createAndGo(4)
      }

      In teLinkTable:
      {
         ifIndex                        = 4,
         teLinkAddressType              = unknown(0),
         teLinkLocalIpAddr              = ’’H,
         teLinkRemoteIpAddr             = ’’H,
         teLinkMetric                   = 5,
         teLinkProtectionType           = unprotected(2),
         teLinkWorkingPriority          = 7,
         teLinkResourceClass            = 3,
         teLinkIncomingIfId             = 0,
         teLinkOutgoingIfId             = 4,
         teLinkRowStatus                = createAndGo(4),
         teLinkStorageType              = nonVolatile(3)
      }

      In ifStackTable:
      {
         ifStackHigherLayer             = 2,
         ifStackLowerLayer              = 4,
         ifStackStatus                  = createAndGo(4)
      }

   We assign SRLGs to the TE links.

      In the teLinkSrlgTable:
      {
         ifIndex                        = 3,
         teLinkSrlg                     = 10,
         teLinkSrlgRowStatus            = createAndGo(4),
         teLinkSrlgStorageType          = nonVolatile(3)
      }

      In the teLinkSrlgTable:
      {

         ifIndex                        = 4,
         teLinkSrlg                     = 50,
         teLinkSrlgRowStatus            = createAndGo(4),
         teLinkSrlgStorageType          = nonVolatile(3)
      }

   The bundled link inherits the SRLG properties from the associated TE
   links.

   Next, for each unbundled TE link, a component link is created.  An
   ifEntry with the same ifIndex needs to be created beforehand.

      In componentLinkTable:
      {
         ifIndex                          = 5,
         componentLinkPreferredProtection = primary(1),
         componentLinkRowStatus           = createAndGo(4),
         componentLinkStorageType         = nonVolatile(3)
      }

      In ifStackTable:
      {
         ifStackHigherLayer             = 3,
         ifStackLowerLayer              = 5,
         ifStackStatus                  = createAndGo(4)
      }

      In componentLinkTable:
      {
         ifIndex                          = 6,
         componentLinkPreferredProtection = secondary(2),
         componentLinkRowStatus           = createAndGo(4)
         componentLinkStorageType         = nonVolatile(3)
      }

      In ifStackTable:
      {
         ifStackHigherLayer             = 4,
         ifStackLowerLayer              = 6,
         ifStackStatus                  = createAndGo(4)
      }

   In this example, once a component link is added to the
   componentLinkTable, the associated link descriptors are implicitly
   added to the componentLinkDescriptorTable.

   TE link link descriptors are derived from their component link
   descriptors.

   Note that the bandwidth attributes in teLinkDescriptorTable,
   componentLinkDescriptorTable, teLinkBandwidthTable, and
   componentLinkBandwidthTable are maintained by the device according to
   LSP creation/deletion at different priorities.  The values in the
   teLinkBandwidthTable are an aggregation of the values for the
   component links of the TE links and the TE links of the bundled link.

8.  Application of the Interfaces Group to TE Links

   The Interfaces Group [RFC2863] defines generic managed objects for
   managing interfaces.  This memo contains the media-specific
   extensions to the Interfaces Group for managing TE Link interfaces as
   logical interfaces.

   This memo assumes the interpretation of the Interfaces Group to be in
   accordance with [RFC2863], which states that the interfaces table
   (ifTable) contains information on the managed resource’s interfaces
   and that each sub-layer below the internetwork layer of a network
   interface is considered an interface.  Thus, the TE Link interface is
   represented as an entry in the ifTable.  The interrelation of entries
   in the ifTable is defined by Interfaces Stack Group, as defined in
   [RFC2863].

   When using TE Link interfaces, the interface stack table might appear
   as follows:

      +----------------------------------------+
      | TE link-interface ifType = teLink(200) +
      +----------------------------------------+
      | Underlying Layer...                    +
      +----------------------------------------+

   In the above diagram, "Underlying Layer..." refers to the ifIndex of
   any interface type, which has been defined for TE Link interworking.
   Examples include ATM, Frame Relay, Ethernet, etc.

8.1.  Support of the TE Link Layer by ifTable

   Some specific interpretations of ifTable for the TE Link layer
   follow.

   Object        Use for the TE Link layer

   ifIndex       Each TE Link interface is represented by an ifEntry.

   ifDescr       Description of the TE Link interface.

   ifType        The value that is allocated for TE Link is 200
                 [IANAifType].

   ifSpeed       The total bandwidth in bits per second for use by the
                 TE Link layer.

   ifPhysAddress Unused.

   ifAdminStatus This variable indicates the administrator’s intent as
                 to whether TE Link should be enabled, disabled, or
                 running in some diagnostic testing mode on this
                 interface.  Also see [RFC2863].

   ifOperStatus  This value reflects the actual or operational status of
                 the TE Link on this interface.

   ifLastChange  See [RFC2863].

   ifInOctets    The number of received octets over the interface, i.e.,
                 the number of received octets in all component links
                 associated with the interface.

   ifOutOctets   The number of transmitted octets over the interface,
                 i.e., the number of octets transmitted over all
                 component links associated with the interface.

   ifInErrors    The number of packets dropped due to uncorrectable
                 errors.

   ifInUnknownProtos
                 The number of received packets discarded during packet
                 header validation.

   ifOutErrors   See [RFC2863].

   ifName        Textual name (unique on this system) of the interface,
                 or an octet string of zero length.

   ifLinkUpDownTrapEnable
                 Default is disabled (2).

   ifConnectorPresent
                 Set to false (2).

   ifHighSpeed   See [RFC2863].

   ifHCInOctets  The 64-bit version of ifInOctets; supported if required
                 by the compliance statements in [RFC2863].

   ifHCOutOctets The 64-bit version of ifOutOctets; supported if
                 required by the compliance statements in [RFC2863].

   ifAlias       The non-volatile ’alias’ name for the interface, as
                 specified by a network manager.

   ifCounterDiscontinuityTime
                 See [RFC2863].

   Support for ifInOctets, ifOutOctets, ifInErrors, ifInUnknownProtos,
   ifOutErrors, ifHCInOctets, and ifHCOutOctets objects is not required
   if the encoding type is clear.  For other encoding types, traffic
   counters on a TE link are cumulative for all subinterfaces that it
   binds together.

8.2.  Using ifStackTable

   This section describes, by example, how to use the ifStackTable to
   represent the relationship of TE links with underlying TE-enabled
   interfaces.  Implementors of the stack table for TE link interfaces
   should look at the appropriate RFC for the service being stacked on
   TE links.  The examples given below are for illustration purposes
   only.

      Example: MPLS is being carried on a bundled TE link.  The bundled
               TE link represents a 1:1 optical transport interface.

   In this example, the component link is a TE link.  The two component
   links/TE links are grouped in a bundled link.

   +-------------------------------------------------------------------+
   | MPLS interface ifType = mpls(166)                                 |
   | ifIndex = 1                                                       |
   +-------------------------------------------------------------------+
   | TE link (bundled link) ifType = teLink(200)                       |
   | ifIndex = 2                                                       |
   +--------------------------------+-+--------------------------------+
   | TE link ifType = teLink(200)   | | TE link ifType = teLink(200)   |
   | ifIndex = 3                    | | ifIndex = 4                    |
   +--------------------------------+ +--------------------------------+
   | Component link                 | | Component link                 |
   | ifType = opticalTransport(196) | | ifType = opticalTransport(196) |
   | ifIndex = 5                    | | ifIndex = 6                    |
   +--------------------------------+ +--------------------------------+

   The assignment of the index values could, for example, be:

            ifIndex  Description
            1        mpls             (type 166)
            2        teLink           (type 200)
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容