--- 1/draft-ietf-mpls-p2mp-te-mib-04.txt 2007-09-24 20:12:09.000000000 +0200 +++ 2/draft-ietf-mpls-p2mp-te-mib-05.txt 2007-09-24 20:12:09.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group A. Farrel (Editor) INTERNET-DRAFT Old Dog Consulting -Updates: RFC3812 +Updates: RFC3812, RFC4802 Intended Status: Standards Track S. Yasukawa -Expires: January 2008 NTT - +Created: September 24, 2007 NTT +Expires: March 24, 2008 T. Nadeau - Cisco Systems, Inc. + BT Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module - draft-ietf-mpls-p2mp-te-mib-04.txt + draft-ietf-mpls-p2mp-te-mib-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -35,62 +35,68 @@ accessed at http://www.ietf.org/shadow.html. Abstract This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). + The MIB module defined in this document is applicable to P2MP MPLS-TE + by extensions to the MPLS-TE MIB module defined in RFC 3812. It is + equally applicable to P2MP Generalized MPLS (GMPLS) in association + with the GMPLS TE MIB module defined in RFC 4802. + Table of Contents 1. Introduction .................................................. 2 2. The Internet-Standard Management Framework .................... 3 - 3. Feature List .................................................. 3 + 3. Feature List .................................................. 4 4. Outline ....................................................... 4 4.1. Summary of the P2MP MPLS Traffic Engineering MIB Module .. 5 - 4.2. Use of MPLS-TE-STD-MIB ................................... 5 - 4.3. Scalars .................................................. 7 - 4.3. mplsTeP2mpTunnelTable .................................... 8 - 4.5. mplsTeP2mpTunnelDestTable ................................ 8 - 4.6. mplsTeP2mpTunnelBranchPerfTable .......................... 8 - 4.7. Relationships Between MIB Tables ......................... 9 - 5. Using the P2MP MPLS-TE MIB Module ............................. 9 - 5.1. Example Use of the P2MP MPLS-TE MIB Module .............. 10 - 6. Managing P2MP MPLS-TE LSPs Through the LSR MIB Module ........ 15 - 6.1. Example Use of the LSR MIB Module ....................... 16 - 7. MPLS Traffic Engineering P2MP MIB Definitions ................ 19 - 8. Security Considerations ...................................... 43 - 9. Acknowledgments .............................................. 44 - 10. IANA Considerations .......................................... 45 - 10.1. IANA Considerations for MPLS-TE-P2MP-STD-MIB ............ 45 - 11. References ................................................... 45 - 11.1. Normative References .................................... 45 - 11.2. Informative References ..................................... 46 - 12. Authors' Addresses ........................................... 47 - 13. Intellectual Property ........................................ 47 - 14. Full Copyright Statement ..................................... 48 + 4.2. Use of MPLS-TE-STD-MIB ................................... 6 + 4.3. Scalars ................................................. 10 + 4.3. mplsTeP2mpTunnelTable ................................... 10 + 4.5. mplsTeP2mpTunnelDestTable ............................... 10 + 4.6. mplsTeP2mpTunnelBranchPerfTable ......................... 10 + 4.7. Relationships Between MIB Tables ........................ 11 + 5. Using the P2MP MPLS-TE MIB Module ............................ 11 + 5.1. Example Use of the P2MP MPLS-TE MIB Module .............. 12 + 5.2. Example Transit LSR Inspection .......................... 17 + 6. Managing P2MP MPLS-TE LSPs Through the LSR MIB Module ........ 23 + 6.1. Example Use of the LSR MIB Module ....................... 24 + 7. MPLS Traffic Engineering P2MP MIB Definitions ................ 27 + 8. Security Considerations ...................................... 53 + 9. Acknowledgments .............................................. 55 + 10. IANA Considerations .......................................... 55 + 10.1. IANA Considerations for MPLS-TE-P2MP-STD-MIB ............ 55 + 11. References ................................................... 55 + 11.1. Normative References .................................... 55 + 11.2. Informative References .................................. 56 + 12. Authors' Addresses ........................................... 57 + 13. Intellectual Property ........................................ 57 + 14. Full Copyright Statement ..................................... 58 0. Changes Since Previous Revision [This section to be removed before publication as an RFC.] - Updates after early MIB Doctor review. - - Fix compiler warnings - - Minor clarifications in Abstract and Overview sections - - Add conformance statements for objects of syntax InetAddressType - - Clarifications to various Description clauses - - Delete mplsTeP2mpTunnelIsP2MP - - Allow mplsTeP2mpTunnelSubGroupOrigin to have zero length when - mplsTeP2mpTunnelSubGroupOrigin is set to unknown(0) - - Change syntax of mplsTeP2mpTunnelSubGroupID to IndexInteger + - Clarify that this MIB module is equally applicable to GMPLS + (Abstract and section 1). + - Add explanation of how backward compatibility is not impacted by + the modification of semantics for objects in the MPLS-TE-STD-MIB. + (Sections 4.2.1 and 4.2.2.) + - Add section 5.2 for transit node example. + - Expand conformance statements for read-only and read-create cases. + - Fix smilint warnings. + - Typos. 1. Introduction 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 point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) traffic engineering (TE). MPLS is defined in [RFC3031] and a signaling protocol for @@ -107,20 +113,25 @@ This document defines a MIB module for managing and controlling P2MP MPLS-TE. It builds on the objects and tables defined in [RFC3812] so that P2MP MPLS-TE management is an extension of P2P MPLS-TE management. In addition, this document provides a description of how to use the LSR MIB module [RFC3813] to model and control an LSR that supports P2MP MPLS-TE. + The MIB module defined in this document and the usage of the LSR MIB + module are equally applicable to Generalized MPLS (GMPLS) in + association with the GMPLS TE MIB module defined in [RFC4802] and the + GMPLS LSR MIB module defined in [RFC4803]. + 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 BCP 14, RFC 2119 [RFC2119]. 2. 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]. @@ -328,20 +340,114 @@ If the tunnel is a P2MP tunnel as indicated by the presence of an entry in the mplsTeP2mpTunnelTable corresponding to this tunnel, this object is not used. This is because the destinations and paths to those destinations are found in the mplsTeP2mpTunnelDestTable. If this object is present for a P2MP tunnel, it SHOULD contain the value 0. +4.2.1. Backward Compatiblity Concerns for MIB Read Operations + + A concern may be raised with regard to the changed semantics of the + objects listed in Section 4.2 within the MPLS-TE-STD-MIB module. What + would happen if an implementation that was not P2MP-aware attempted + to read from the MPLS-TE-STD-MIB module and encountered these objects + with changed semantics? Would it attempt to handle a P2MP LSP as a + P2P LSP, and would this potentially cause damage to the + implementation? + + To clarify the situation, each of the objects with modified semantics + is set out below. The term 'legacy system' is used to refer to a + management station that is not aware of the P2MP-TE-STD-MIB and is + not aware of the modified sematics of these objects. + + mplsTunnelMaxHops + If examined by a legacy system, this object will be correctly + interpreted as it continues to refer to the number of hops to any + single destination. A legacy system will look to this object to + determine how many hops it may insert into the path of a P2P LSP, + and it will get the correct result from this object. + + mplsTunnelEgressLSRId + This object reflects the value used in the signaling protocol in + the Session Object. Although the precise semantic of the field is + different in P2P and P2MP signaling, the use of the field as part + of the tuple that identifies the LSP is unchanged. + + If a P2MP tunnel is examined by a legacy system, this object will + be correctly interpreted as the same size and format, and will be + used to identify the LSP. This will not impact the operation of + the legacy system. + + mplsTunnelHopTableIndex + If a P2MP tunnel is examined by a legacy system, this object will + report zero giving the impression that no tunnel hops have been + configured. This will not impact the operation of the legacy + system. + + mplsTunnelPathInUse + If a P2MP tunnel is examined by a legacy system, this object will + report zero giving the impression that no path is in use or + available. This will not impact the operation of the legacy + system. + + mplsTunnelARHopTableIndex + If a P2MP tunnel is examined by a legacy system, this object will + report zero giving the impression that no tunnel hops have been + reported by the signaling protocol. This is a valid scenario and + will not impact the operation of the legacy system. + + mplsTunnelCHopTableIndex + If a P2MP tunnel is examined by a legacy system, this object will + report zero giving the impression that no tunnel hops have been + computed. This is a valid scenario and will not impact the + operation of the legacy system. + +4.2.2. Backward Compatiblity Concerns for MIB Write Operations + + Although a legacy system may be able to read objects in the + MPLS-TE-STD-MIB which have modified semantics and operate correctly, + there is also a concern that the legacy system might try to write to + these objects, thus modifying the P2MP LSP in an unexpected way. + + This section lists the objects with modified semantics and explains + how each is safe against write access by a legacy system. + + mplsTunnelMaxHops + If set by a legacy system, this object will correctly control the + mximum number of hops in an LSP to a single destination as + expected by the legac system. + + mplsTunnelEgressLSRId + A legacy system that was used to modify this object for a P2MP + tunnel would be successful and would not damage the operation of + the P2MP tunnel. All that would happen is that the identity of the + tunnel would be changed. + + mplsTunnelHopTableIndex + If this object is set for a P2MP tunnel by a legacy system, the SET + will be successful, but the value (i.e. the object) will be ignored + by the management agent and the object will not be used. + + mplsTunnelPathInUse + If this object is set for a P2MP tunnel by a legacy system, the SET + will be successful, but the value (i.e. the object) will be ignored + by the management agent and the oobject will not be used. + + mplsTunnelARHopTableIndex + This object is read-only and cannot be set. + + mplsTunnelCHopTableIndex + This object is read-only and cannot be set. + 4.3. Scalars There are three scalars defined for this MIB module. mplsTeP2mpTunnelConfigured provides a read-only counter of the number of P2MP MPLS-TE tunnels that are configured on this LSR through this MIB module. mplsTeP2mpTunnelActive provides a read-only counter of the number of P2MP MPLS-TE tunnels configured on this LSR through this MIB module @@ -504,21 +609,21 @@ mplsTunnelResourceRowStatus = createAndGo(4) } Step 2 - Define the core parameters for the LSP tunnel. In mplsTunnelTable define as follows: { mplsTunnelIndex = 4, mplsTunnelInstance = 0, - mplsTunnelIngressLSRId = 192.0.2.1, + mplsTunnelIngressLSRId = "192.0.2.1", -- The tunnel egress LSR ID is used to -- hold the P2MP ID for the P2MP LSP tunnel mplsTunnelEgressLSRId = 328, mplsTunnelName = "My first P2MP tunnel", mplsTunnelDescr = "Here to there and there", mplsTunnelIsIf = true(1), -- There is no cross-connect present yet mplsTunnelXCPointer = 0.0, -- This table entry is created by configuration no signaling mplsTunnelSignallingProto = rsvp(2), @@ -547,21 +653,21 @@ Step 3 - Create the P2MP Tunnel In mplsTeP2mpTunnelTable define as follows: { mplsTeP2mpTunnelP2mpIntegrity = true(1), -- This is the head end of the LSP and not a branch mplsTeP2mpTunnelBranchRole = notBranch(1), mplsTeP2mpTunnelSubGroupOriginType = ipv4(1), - mplsTeP2mpTunnelSubGroupOrigin = 192.0.2.1, + mplsTeP2mpTunnelSubGroupOrigin = "192.0.2.1", mplsTeP2mpTunnelSubGroupID = 132, mplsTeP2mpTunnelRowStatus = createAndGo(4) } Step 4 - Create the configured explicit routes for the LSP Two pieces of explicit path are required. The first runs from R to D1, and the second from B to D2. See [RFC4875] for a discussion of the construction of explicit routes for P2MP MPLS-TE LSPs. @@ -664,55 +769,327 @@ mplsTunnelHopEntryPathComp = explicit(2), mplsTunnelHopRowStatus = createAndGo(4) } Step 5 - Create the destinations for the P2MP LSP tunnel In mplsTeP2mpTunnelDestTable define as follows: { mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1), - mplsTeP2mpTunnelDestSubGroupOrigin = 192.0.2.1, + mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.1", mplsTeP2mpTunnelDestSubGroupID = 132, mplsTeP2mpTunnelDestDestinationType = ipv4(1), - mplsTeP2mpTunnelDestDestination = 192.0.2.65, + mplsTeP2mpTunnelDestDestination = "192.0.2.65", mplsTeP2mpTunnelDestHopTableIndex = 1, mplsTeP2mpTunnelDestPathInUse = 1, mplsTeP2mpTunnelDestAdminStatus = up(1), mplsTeP2mpTunnelDestRowStatus = createAndGo(4) } { mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1), - mplsTeP2mpTunnelDestSubGroupOrigin = 192.0.2.1, + mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.1", mplsTeP2mpTunnelDestSubGroupID = 132, mplsTeP2mpTunnelDestDestinationType = ipv4(1), - mplsTeP2mpTunnelDestDestination = 192.0.2.66, + mplsTeP2mpTunnelDestDestination = "192.0.2.66", mplsTeP2mpTunnelDestHopTableIndex = 2, mplsTeP2mpTunnelDestPathInUse = 1, mplsTeP2mpTunnelDestAdminStatus = up(1), mplsTeP2mpTunnelDestRowStatus = createAndGo(4) } Step 6 - Activate the tunnel In mplsTunnelTable define as follows: { mplsTunnelIndex = 4, mplsTunnelInstance = 0, - mplsTunnelIngressLSRId = 192.0.2.1, + mplsTunnelIngressLSRId = "192.0.2.1", mplsTunnelEgressLSRId = 328, -- Activate the tunnel mplsAdminStatus = up(1) } +5.2. Example Transit LSR Inspection + + The MPLS-TE-P2MP-STD-MIB module can be used at the head end of a P2MP + LSP to configure, manage, and monitor the LSP. This is described in + Section 5.1. + + The MIB module may also be used to monitor P2MP LSPs at transit and + egress LSRs. Although many objects in the MIB module is writeable, as + with MPLS-TE-STD-MIB, those objects are not normally writeable except + at the head end LSRs. + + This section provides a simple example of the use of the P2MP MPLS-TE + MIB module at a transit LSR where the module is used to inspect the + LSPs. The example uses the topology shown in Figure 2 and the LSP set + out in Section 5.1. Consider the situation at LSR B in the figure. + + LSR will receive a single Path message from LSR A and will send a + Path message onwards to LSRs C1 and C2. Similarly, LSR B will receive + Resv messages from LSRs C1 and C2, and will send a Resv to LSR A. + Once the LSP has been set up and the signaling protocol has reached a + stable state, the tables in the MPLS-TE-STD-MIB and + MPLS-TE-P2MP-STD-MIB can be read as follows. + + An entry in mplsTunnelTable provides the base information for the + P2MP tunnel. + + { + mplsTunnelIndex = Path.Session.TunnelID + mplsTunnelInstance = Path.SenderTemplate.LSP_ID + mplsTunnelIngressLSRId = Path.Session.ExtendedTunnelID + mplsTunnelEgressLSRId = Path.Session.P2MPID + mplsTunnelName = Path.SessionAttribute.SessionName + mplsTunnelDescr = absent ("") or autogenerated + mplsTunnelIsIf = false(2) + mplsTunnelIfIndex = 0 + mplsTunnelOwner = rsvpTe(6) + mplsTunnelRole = transit(2) or tail(3) + mplsTunnelXCPointer = points to a row in the mplsXCTable + mplsTunnelSignallingProto = rsvp(2) + mplsTunnelSetupPrio = Path.SessionAttribute.SetupPr + mplsTunnelHoldingPrio = Path.SessionAttribute.HoldPr + mplsTunnelSessionAttributes = Path.SessionAttribute.Flags + mplsTunnelLocalProtectInUse = Resv.RecordRoute.Flags + mplsTunnelResourcePointer = points to the traffic parameter + specification for this tunnel + mplsTunnelPrimaryInstance = mplsTunnelInstance + mplsTunnelInstancePriority = 0 + mplsTunnelHopTableIndex = 0 + mplsTunnelPathInUse = 0 + mplsTunnelARHopTableIndex = 0 + mplsTunnelCHopTableIndex = 0 + mplsTunnelIncludeAnyAffinity= Path.SeesionAttribute.IncludeAny + mplsTunnelIncludeAllAffinity= Path.SeesionAttribute.IncludeAll + mplsTunnelExcludeAnyAffinity= Path.SeesionAttribute.ExcludeAny + mplsTunnelTotalUpTime = time since Resv sent + mplsTunnelInstanceUpTime = time since Resv sent + mplsTunnelPrimaryUpTime = time since Resv sent + mplsTunnelPathChanges = 0 + mplsTunnelLastPathChange = time since Resv sent + mplsTunnelCreationTime = time since Resv sent + mplsTunnelStateTransitions = 1 + mplsTunnelAdminStatus = up(1) + mplsTunnelOperStatus = up(1) + mplsTunnelRowStatus = active(1) + mplsTunnelStorageType = volatile(2) + } + An entry in mplsTeP2mpTunnelTable indicates that the tunnel is a P2MP + tunnel, and provides the parameters speicific to its P2MP nature. The + index objects (mplsTunnelIndex, mplsTunnelInstance, + mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId) are identical in + value to the entry in the mplsTunnelTable. + + { + mplsTeP2mpTunnelP2mpIntegrity = Path.LSPAttributes.Flags + mplsTeP2mpTunnelBranchRole = branch(2) + mplsTeP2mpTunnelSubGroupOriginType = ipv4(1) + mplsTeP2mpTunnelSubGroupOrigin = Path.SenderTemplate.SubGpOrigin + mplsTeP2mpTunnelSubGroupID = Path.SenderTemplate.SubGpID + mplsTeP2mpTunnelRowStatus = active(1) + mplsTeP2mpTunnelStorageType = volatile(2) + } + + Two entries are required in the mplsTeP2mpTunnelDestTable. Index + values of the mplsTeP2mpTunnelDestSubGroupID object will have been + assigned automatically and will not have been generated by reading + the mplsTeP2mpTunnelSubGroupIDNext object. Other index values + (mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, and + mplsTunnelEgressLSRId) are identical in value to those in the entry + in the mplsTunnelTable and the mplsTeP2mpTunnelTable. The remaining + index values are determined from the local LSR's address and the + destinations of the P2MP tunnel. + + { + mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1) + mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.17" + mplsTeP2mpTunnelDestSubGroupID = 1 + mplsTeP2mpTunnelDestDestinationType = ipv4(1) + mplsTeP2mpTunnelDestDestination = "192.0.2.65" + mplsTeP2mpTunnelDestBranchOutSegment + = index into mplsOutSegmentTable + mplsTeP2mpTunnelDestHopTableIndex + = index into the mplsTunnelHopTable + mplsTeP2mpTunnelDestPathInUse = 1 + mplsTeP2mpTunnelDestCHopTableIndex + = index into the mplsTunnelCHopTable + mplsTeP2mpTunnelDestARHopTableIndex + = index into the mplsTunnelARHopTable + mplsTeP2mpTunnelDestTotalUpTime = time since Resv sent + mplsTeP2mpTunnelDestInstanceUpTime = time since Resv sent + mplsTeP2mpTunnelDestPathChanges = 1 + mplsTeP2mpTunnelDestLastPathChange = time since Resv sent + mplsTeP2mpTunnelDestCreationTime = time since Resv sent + mplsTeP2mpTunnelDestStateTransitions = 1 + mplsTeP2mpTunnelDestDiscontinuityTime = 0 + mplsTeP2mpTunnelDestAdminStatus = up(1) + mplsTeP2mpTunnelDestOperStatus = up(1) + mplsTeP2mpTunnelDestRowStatus = active(1) + mplsTeP2mpTunnelDestStorageType = volatile(2) + } + + { + mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1) + mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.17" + mplsTeP2mpTunnelDestSubGroupID = 2 + mplsTeP2mpTunnelDestDestinationType = ipv4(1) + mplsTeP2mpTunnelDestDestination = "192.0.2.66" + mplsTeP2mpTunnelDestBranchOutSegment + = index into mplsOutSegmentTable + mplsTeP2mpTunnelDestHopTableIndex + = index into the mplsTunnelHopTable + mplsTeP2mpTunnelDestPathInUse = 1 + mplsTeP2mpTunnelDestCHopTableIndex + = index into the mplsTunnelCHopTable + mplsTeP2mpTunnelDestARHopTableIndex + = index into the mplsTunnelARHopTable + mplsTeP2mpTunnelDestTotalUpTime = time since Resv sent + mplsTeP2mpTunnelDestInstanceUpTime = time since Resv sent + mplsTeP2mpTunnelDestPathChanges = 1 + mplsTeP2mpTunnelDestLastPathChange = time since Resv sent + mplsTeP2mpTunnelDestCreationTime = time since Resv sent + mplsTeP2mpTunnelDestStateTransitions = 1 + mplsTeP2mpTunnelDestDiscontinuityTime = 0 + mplsTeP2mpTunnelDestAdminStatus = up(1) + mplsTeP2mpTunnelDestOperStatus = up(1) + mplsTeP2mpTunnelDestRowStatus = active(1) + mplsTeP2mpTunnelDestStorageType = volatile(2) + } + + A single entry in mplsTunnelResourceTable is automatically created to + reflect the reservation request on the upstream segment and both of + the downstream branches. The information is gathered from the + received Path message. The table entry is pointed to by + mplsTunnelResourcePointer. + + The index value (mplsTunnelResourceIndex) is automatically generated. + + { + mplsTunnelResourceIndex = 33 + mplsTunnelResourceMaxRate = 0 + mplsTunnelResourceMeanRate = 0 + mplsTunnelResourceMaxBurstSize = 0 + mplsTunnelResourceMeanBurstSize = 0 + mplsTunnelResourceExBurstSize = 0 + mplsTunnelResourceExBurstSize = unspecified(1) + mplsTunnelResourceWeight = 0 + mplsTunnelResourceRowStatus = active(1) + mplsTunnelResourceStorageType = volatile(2) + } + + Finally, entries may also be read from the tunnel hop tables. + mplsTunnelHopTable contains the route information received in the + incoming Path message. It is spearated out to refer to the two + separate downstream branches, and the entries are identified by the + corresponding values of mplsTeP2mpTunnelDestHopTableIndex. There are + four hops in total in our example. + + { + mplsTunnelHopListIndex = 27 + mplsTunnelPathOptionIndex = 1 + mplsTunnelHopIndex = 1 + mplsTunnelHopAddrType = ipv4(1) + mplsTunnelHopIpAddr = "192.0.2.33" + mplsTunnelHopIpPrefixLen = 32 + mplsTunnelHopType = strict(2) + mplsTunnelHopInclude = true(1) + mplsTunnelHopPathOptionName = "" + mplsTunnelHopEntryPathComp = explicit(2) + mplsTunnelHopRowStatus = active(1) + mplsTunnelHopStorageType = volatile(2) + } + + { + mplsTunnelHopListIndex = 27 + mplsTunnelPathOptionIndex = 1 + mplsTunnelHopIndex = 2 + mplsTunnelHopAddrType = ipv4(1) + mplsTunnelHopIpAddr = "192.0.2.65" + mplsTunnelHopIpPrefixLen = 32 + mplsTunnelHopType = strict(2) + mplsTunnelHopInclude = true(1) + mplsTunnelHopPathOptionName = "" + mplsTunnelHopEntryPathComp = explicit(2) + mplsTunnelHopRowStatus = active(1) + mplsTunnelHopStorageType = volatile(2) + } + + { + mplsTunnelHopListIndex = 33 + mplsTunnelPathOptionIndex = 1 + mplsTunnelHopIndex = 1 + mplsTunnelHopAddrType = ipv4(1) + mplsTunnelHopIpAddr = "192.0.2.34" + mplsTunnelHopIpPrefixLen = 32 + mplsTunnelHopType = strict(2) + mplsTunnelHopInclude = true(1) + mplsTunnelHopPathOptionName = "" + mplsTunnelHopEntryPathComp = explicit(2) + mplsTunnelHopRowStatus = active(1) + mplsTunnelHopStorageType = volatile(2) + } + + { + mplsTunnelHopListIndex = 33 + mplsTunnelPathOptionIndex = 1 + mplsTunnelHopIndex = 2 + mplsTunnelHopAddrType = ipv4(1) + mplsTunnelHopIpAddr = "192.0.2.66" + mplsTunnelHopIpPrefixLen = 32 + mplsTunnelHopType = strict(2) + mplsTunnelHopInclude = true(1) + mplsTunnelHopPathOptionName = "" + mplsTunnelHopEntryPathComp = explicit(2) + mplsTunnelHopRowStatus = active(1) + mplsTunnelHopStorageType = volatile(2) + } + + If the mplsTunnelCHopTable is used (and it might be used to supply + information about path expansions) the contents will, for this + example, be identical to the entries in the mplsTunnelHopTable + since strict explicit routes were used. + + The mplsTunnelARHopTable is used to expose the information reported in + the Record Route object carried in the Resv message. In this example, + thre would also be four entries as shown below. + + { + mplsTunnelARHopListIndex = 12 + mplsTunnelARHopIndex = 1 + mplsTunnelARHopAddrType = ipv4(1) + mplsTunnelARHopIpAddr = "192.0.2.33" + } + + { + mplsTunnelARHopListIndex = 12 + mplsTunnelARHopIndex = 2 + mplsTunnelARHopAddrType = ipv4(1) + mplsTunnelARHopIpAddr = "192.0.2.65" + } + + { + mplsTunnelARHopListIndex = 197 + mplsTunnelARHopIndex = 1 + mplsTunnelARHopAddrType = ipv4(1) + mplsTunnelARHopIpAddr = "192.0.2.34" + } + { + mplsTunnelARHopListIndex = 197 + mplsTunnelARHopIndex = 2 + mplsTunnelARHopAddrType = ipv4(1) + mplsTunnelARHopIpAddr = "192.0.2.66" + } + 6. Managing P2MP MPLS-TE LSPs Through the LSR MIB Module The nature of P2MP tunnels is such that an LSR that is crossed by a tunnel may either be the ingress of that tunnel or have precisely one upstream LSP segment (also known as an in-segment [RFC3812]) for that LSP. On the other hand, any LSR that is crossed by a tunnel may be an egress for that tunnel, have one or more downstream segments (also known as out-segments [RFC3812]) for that tunnel, or be both an egress and have one or more out-segments. Thus, for an LSP at an LSR there may be zero or one in-segments, and zero, one, or more than one @@ -871,61 +1247,62 @@ mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId FROM MPLS-TE-STD-MIB -- RFC 3812 IndexInteger, IndexIntegerNextFree FROM DIFFSERV-MIB -- RFC 3289 InetAddress, InetAddressType FROM INET-ADDRESS-MIB -- RFC 4001 ; mplsTeP2mpStdMIB MODULE-IDENTITY - LAST-UPDATED "200702240000Z" -- February 24, 2007 + LAST-UPDATED "200709170000Z" -- Setember 17, 2007 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Seisho Yasukawa NTT Corporation Email: s.yasukawa@hco.ntt.co.jp Thomas D. Nadeau - Cisco Systems, Inc. - Email: tnadeau@cisco.com + British Telecom + Email: thomas.nadeau@bt.com Comments about this document should be emailed directly to the MPLS working group mailing list at mpls@lists.ietf.org" DESCRIPTION "Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC XXXX. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html -- RFC Editor. Please replace XXXX with the RFC number for this -- document and remove this note. This MIB module contains managed object definitions for Point-to-Multipoint (P2MP) MPLS Traffic Engineering (TE) defined in: 1. Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs), S. Yasukawa, RFC 4461, April 2006. - 2. Extensions to RSVP-TE for Point to Multipoint TE LSPs, - R. Aggarwal, S. Yasukawa, and D. Papadimitriou, work in - progress." + 2. Extensions to Resource Reservation Protocol - Traffic + Engineering (RSVP-TE) for Point-to-Multipoint TE Label + Switched Paths (LSPs), Aggarwal, R., Papadimitriou, D., + and Yasukawa, S., RFC 4875, May 2007." -- Revision history. REVISION - "200702240000Z" -- February 24, 2007 + "200709170000Z" -- Setember 17, 2007 DESCRIPTION "Initial version issued as part of RFC XXXX." -- RFC Editor. Please replace XXXX with the RFC number for this -- document and remove this note. ::= { mplsStdMIB YYY } -- RFC Editor. Please replace YYY with the codepoint issued by IANA -- and remove this note. @@ -1142,21 +1519,21 @@ Since the object mplsTeP2mpTunnelSubGroupOrigin must conform to the protocol specification, this object must return either ipv4(1) or ipv6(2) at a transit or egress LSR. At an ingress LSR, mplsTeP2mpTunnelSubGroupOrigin should not be used, and this object should return the value unknown(0)." ::= { mplsTeP2mpTunnelEntry 4 } mplsTeP2mpTunnelSubGroupOrigin OBJECT-TYPE - SYNTAX InetAddress (SIZE (0..16)) + SYNTAX InetAddress (SIZE(0|4|16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The TE Router ID (reachable and stable IP address) of the originator of the P2MP sub-group as received on a Path message by a transit or egress LSR. This object is interpreted in the context of mplsTeP2mpTunnelSubGroupOriginType. @@ -1294,21 +1671,21 @@ Note that the same destination may be present more than once if it is in more than one sub-group as reflected by the mplsTeP2mpTunnelDestSubGroupOriginType, mplsTeP2mpTunnelDestSubGroupOrigin, and mplsTeP2mpTunnelDestSubGroupID, index objects. Entries in this table may be created at any time. If created before an entry in the mplsTeP2mpTunnelTable the entries have no meaning, but may be kept ready for the creation of the P2MP tunnel. If created after the entry in - mplsTeP2mpTunnelTable, entries in table may reflect the + mplsTeP2mpTunnelTable, entries in this table may reflect the addition of destinations to active P2MP tunnels. For this reason, entries in this table are equipped with row, admin, and oper status objects. " REFERENCE "RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004." INDEX { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, @@ -1353,21 +1730,21 @@ mplsTeP2mpTunnelDestSubGroupOrigin. This object forms part of the index of this table and can, therefore, not return the value unknown(0). Similarly, since the object mplsTeP2mpTunnelDestSubGroupOrigin must conform to the protocol specification, this object must return either ipv4(1) or ipv6(2)." ::= { mplsTeP2mpTunnelDestEntry 1 } mplsTeP2mpTunnelDestSubGroupOrigin OBJECT-TYPE - SYNTAX InetAddress (SIZE (1..16)) + SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The TE Router ID (reachable and stable IP address) of the originator of the P2MP sub-group. In many cases, this will be the ingress LSR of the P2MP tunnel and will be the received signaled value as available in mplsTeP2mpTunnelSubGroupOrigin. When a signaling protocol is used, this object corresponds @@ -1410,21 +1787,21 @@ "This object identifies the type of address carried in mplsTeP2mpTunnelDestDestination. This object forms part of the index of this table and can, therefore, not return the value unknown(0). Similarly, since the object mplsTeP2mpTunnelDestDestination must conform to the protocol specification, this object must return either ipv4(1) or ipv6(2)." ::= { mplsTeP2mpTunnelDestEntry 4 } mplsTeP2mpTunnelDestDestination OBJECT-TYPE - SYNTAX InetAddress (SIZE (1..16)) + SYNTAX InetAddress (SIZE(4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single destination of this P2MP tunnel. That is, a routable TE address of a leaf. This will often be the TE Router ID of the leaf, but can be any interface address. When a signaling protocol is used, this object corresponds to the S2L Sub-LSP destination address field in the S2L_SUB_LSP object. @@ -1737,21 +2114,21 @@ mplsTeP2mpTunnelBranchPerfBranch MplsIndexType, mplsTeP2mpTunnelBranchPerfPackets Counter32, mplsTeP2mpTunnelBranchPerfHCPackets Counter64, mplsTeP2mpTunnelBranchPerfErrors Counter32, mplsTeP2mpTunnelBranchPerfBytes Counter32, mplsTeP2mpTunnelBranchPerfHCBytes Counter64, mplsTeP2mpTunnelBranchDiscontinuityTime TimeStamp } mplsTeP2mpTunnelBranchPerfBranch OBJECT-TYPE - SYNTAX MplsIndexType fish + SYNTAX MplsIndexType MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object identifies an outgoing branch from this LSR for this tunnel. Its value is unique within the context of the tunnel. If MPLS-LSR-STD-MIB is implemented, this object should contain an index into mplsOutSegmentTable. @@ -1888,79 +2265,161 @@ This reporting of state transitions mirrors mplsTunnelDown." REFERENCE "RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004." ::= { mplsTeP2mpNotifications 2 } -- End of notifications. - -- Module compliance. + --**************************************************************** + -- Module Conformance Statement + --**************************************************************** mplsTeP2mpGroups OBJECT IDENTIFIER ::= { mplsTeP2mpConformance 1 } mplsTeP2mpCompliances OBJECT IDENTIFIER ::= { mplsTeP2mpConformance 2 } + -- + -- Full Compliance -- Compliance requirement for fully compliant implementations. + -- Such implementations allow configuration of P2MP tunnels at + -- head-end LSRs via SNMP, and monitoring of P2MP tunnels at all + -- LSRs via SNMP. + -- mplsTeP2mpModuleFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance statement for agents that provide full support for MPLS-TE-P2MP-STD-MIB. Such devices can be monitored and - also be configured using this MIB module." + also be configured using this MIB module. + The Module is implemented with support for read-create and + read-write. In other words, both monitoring and + configuration are available when using this + MODULE-COMPLIANCE." - MODULE -- This module. + MODULE -- this module MANDATORY-GROUPS { - mplsTeP2mpGroup, + mplsTeP2mpGeneralGroup, mplsTeP2mpNotifGroup } -- mplsTeP2mpTunnelTable OBJECT mplsTeP2mpTunnelSubGroupOriginType SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2)} + DESCRIPTION + "An implementation is only required to support + unknown(0), IPv4(1) and IPv6(2) addresses." + + OBJECT mplsTeP2mpTunnelRowStatus + SYNTAX RowStatus { active(1) } + WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } + DESCRIPTION + "Support for createAndWait and notInService is not + required." + + ::= { mplsTeP2mpCompliances 1 } + mplsTeP2mpModuleReadOnlyCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Compliance statement for agents that provide read-only + support for MPLS-TE-P2MP-STD-MIB. Such devices can only be + monitored using this MIB module. + The Module is implemented with support for read-only. In + other words, only monitoring is available by implementing + this MODULE-COMPLIANCE." + + MODULE -- this module + + MANDATORY-GROUPS { + mplsTeP2mpGeneralGroup, + mplsTeP2mpNotifGroup + } + + -- mplsTeP2mpTunnelTable + + OBJECT mplsTeP2mpTunnelP2mpIntegrity MIN-ACCESS read-only DESCRIPTION "Write access is not required." - -- mplsTeP2mpTunnelDestTable + OBJECT mplsTeP2mpTunnelBranchRole + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." - OBJECT mplsTeP2mpTunnelDestSubGroupOriginType + OBJECT mplsTeP2mpTunnelSubGroupOriginType SYNTAX InetAddressType {unknown(0), ipv4(1), ipv6(2)} + DESCRIPTION + "An implementation is only required to support + unknown(0), IPv4(1) and IPv6(2) addresses." + + OBJECT mplsTeP2mpTunnelRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and active(1) is the + only status that needs to be supported." + + OBJECT mplsTeP2mpTunnelStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." - OBJECT mplsTeP2mpTunnelDestDestinationType - SYNTAX InetAddressType {ipv4(1), ipv6(2)} + -- mplsTeP2mpTunnelDestTable + + OBJECT mplsTeP2mpTunnelDestHopTableIndex + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + OBJECT mplsTeP2mpTunnelDestPathInUse MIN-ACCESS read-only DESCRIPTION "Write access is not required." - ::= { mplsTeP2mpCompliances 1 } + OBJECT mplsTeP2mpTunnelDestAdminStatus + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT mplsTeP2mpTunnelDestRowStatus + SYNTAX RowStatus { active(1) } + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and active(1) is the + only status that needs to be supported." + + OBJECT mplsTeP2mpTunnelDestStorageType + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + ::= { mplsTeP2mpCompliances 2 } -- Units of conformance. - mplsTeP2mpGroup OBJECT-GROUP + mplsTeP2mpGeneralGroup OBJECT-GROUP OBJECTS { mplsTeP2mpTunnelConfigured, mplsTeP2mpTunnelActive, mplsTeP2mpTunnelTotalMaxHops, mplsTeP2mpTunnelP2mpIntegrity, mplsTeP2mpTunnelBranchRole, mplsTeP2mpTunnelSubGroupOriginType, mplsTeP2mpTunnelSubGroupOrigin, mplsTeP2mpTunnelSubGroupID, mplsTeP2mpTunnelRowStatus, mplsTeP2mpTunnelStorageType, mplsTeP2mpTunnelSubGroupIDNext, + mplsTeP2mpTunnelDestSubGroupOriginType, + mplsTeP2mpTunnelDestSubGroupOrigin, + mplsTeP2mpTunnelDestSubGroupID, + mplsTeP2mpTunnelDestDestinationType, + mplsTeP2mpTunnelDestDestination, mplsTeP2mpTunnelDestBranchOutSegment, mplsTeP2mpTunnelDestHopTableIndex, mplsTeP2mpTunnelDestPathInUse, mplsTeP2mpTunnelDestCHopTableIndex, mplsTeP2mpTunnelDestARHopTableIndex, mplsTeP2mpTunnelDestTotalUpTime, mplsTeP2mpTunnelDestInstanceUpTime, mplsTeP2mpTunnelDestPathChanges, mplsTeP2mpTunnelDestLastPathChange, mplsTeP2mpTunnelDestCreationTime, @@ -2083,22 +2542,23 @@ Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and cryptographic security enabled. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to only those principals (users) that have legitimate rights to those objects. 9. Acknowledgments - The authors wish to thank Tom Petch and Ben Niven-Jenkins for their - input to this work. Thanks to Zafar Ali for discussions. + The authors wish to thank Tom Petch, Ben Niven-Jenkins, and Markus + Stenberg for their input to this work. Thanks to Zafar Ali for + discussions. Joan Cucchiara provided a very thorough and helpful early MIB Doctor review which caught a lot of issues. Comments should be made directly to the MPLS mailing list at mpls@lists.ietf.org 10. IANA Considerations As requested in MPLS-TC-STD-MIB [RFC3811], MPLS-related standards @@ -2164,65 +2624,71 @@ (LSR) Router Management Information Base (MIB)", RFC 3813, June 2004. [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "TextualConventions for Internet Network Addresses", RFC 3291, May 2002. + [RFC4461] S. Yasukawa, Editor "Signaling Requirements for + Point-to-Multipoint Traffic Engineered MPLS LSPs", + RFC 4461, April 2006. + [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. 11.2. Informative References [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statement for Internet Standard Management Framework", RFC 3410, December 2002. [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005. - [RFC4461] S. Yasukawa, Editor "Signaling Requirements for - Point-to-Multipoint Traffic Engineered MPLS LSPs", - RFC 4461, April 2006. - [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007. + [RFC4803] Nadeau, T. and A. Farrel, "Generalized Multiprotocol + Label Switching (GMPLS) Label Switching Router (LSR) + Management Information Base", RFC 4803, February 2007. + 12. Authors' Addresses Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4769 EMail: s.yasukawa@hco.ntt.co.jp Thomas D. Nadeau - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxborough, MA 01719 - Email: tnadeau@cisco.com + BT + BT Centre + 81 Newgate Street + EC1A 7AJ + London + Email: thomas.nadeau@bt.com 13. 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