文档库 最新最全的文档下载
当前位置:文档库 › rfc5602.Pseudowire (PW) over MPLS PSN Management Information Base (MIB)

rfc5602.Pseudowire (PW) over MPLS PSN Management Information Base (MIB)

rfc5602.Pseudowire (PW) over MPLS PSN Management Information Base (MIB)
rfc5602.Pseudowire (PW) over MPLS PSN Management Information Base (MIB)

Network Working Group D. Zelig, Ed. Request for Comments: 5602 Oversi Category: Standards Track T. Nadeau, Ed. BT July 2009 Pseudowire (PW) over MPLS PSN Management Information Base (MIB)

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 a MIB module for PW operation over

Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs).

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) 2009 IETF Trust and the persons identified as the

document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal

Provisions Relating to IETF Documents in effect on the date of

publication of this document (https://www.wendangku.net/doc/0a15583075.html,/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

This document may contain material from IETF Documents or IETF

Contributions published or made publicly available before November

10, 2008. The person(s) controlling the copyright in some of this

material may not have granted the IETF Trust the right to allow

modifications of such material outside the IETF Standards Process.

Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified

outside the IETF Standards Process, and derivative works of it may

not be created outside the IETF Standards Process, except to format

it for publication as an RFC or to translate it into languages other than English.

Zelig & Nadeau Standards Track [Page 1]

Table of Contents

1. Introduction (2)

2. The Internet-Standard Management Framework (2)

3. Terminology (3)

4. Overview (3)

5. Features Checklist (4)

6. MIB Module Usage (5)

7. PW-MPLS-STD-MIB Example (7)

8. Object Definitions (8)

9. Security Considerations (28)

10. IANA Considerations (29)

11. References (29)

11.1. Normative References (29)

11.2. Informative References (30)

1. Introduction

This document describes a model for managing pseudowire services for transmission over different flavors of MPLS tunnels. The general PW MIB module [RFC5601] defines the parameters global to the PW

regardless of the underlying Packet Switched Network (PSN) and

emulated service. This document is applicable for PWs that use MPLS PSN type in the PW-STD-MIB.

This document describes the MIB objects that define pseudowire

association to the MPLS PSN, in a way that is not specific to the

carried service.

Together, [RFC3811] and [RFC3812] describe the modeling of an MPLS

tunnel, and a tunnel’s underlying cross-connects. This MIB module

supports MPLS-TE PSN, non-TE MPLS PSN (an outer tunnel created by the Label Distribution Protocol (LDP) or manually), and MPLS PW label

only (no outer tunnel).

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

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 Zelig & Nadeau Standards Track [Page 2]

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

3. Terminology

This document uses terminology from the document describing the PW

architecture [RFC3985], [RFC3916], and [RFC4447].

The terms "outbound" and "inbound" in this MIB module are based on

the common practice in the MPLS standards; i.e. "outbound" is toward the PSN. However, where these terms are used in an object name, the object description clarifies the exact packet direction to prevent

confusion with these terms in other documents.

"PSN tunnel" is a general term indicating a virtual connection

between the two Pseudowire Emulation Edge-to-Edge (PWE3) edge

devices. Each tunnel may potentially carry multiple PWs inside. An MPLS tunnel is within the scope of this document.

This document uses terminology from the document describing the MPLS architecture [RFC3031] for MPLS PSN. A Label Switched Path (LSP) is modeled as described in [RFC3811] and [RFC3812] via a series of

cross-connects through one or more Label Switching Routers (LSRs).

In MPLS PSN, a PW connection typically uses a PW label within a

tunnel label [RFC4447]. Multiple pseudowires each with a unique PW

label can share the same tunnel. For PW transport over MPLS, the

tunnel label is known as the "outer" label, while the PW label is

known as the "inner" label. An exception to this is with adjacent

LSRs or the use of a Penultimate Hop Popping (PHP). In this case,

there is an option for PWs to connect directly without an outer

label.

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

4. Overview

The MIB module structure for defining a PW service consists of three layers of MIB modules functioning together. This general model is

defined in the PWE3 architecture [RFC3985]. The layering model is

intended to sufficiently isolate PW services from the underlying PSN layer that carries the emulated service. This is done at the same

time as providing a standard means for connecting any supported

services to any supported PSNs.

Zelig & Nadeau Standards Track [Page 3]

The first layer, known as the service layer, contains service-

specific modules. These modules define service-specific management

objects that interface or collaborate with existing MIB modules for

the native version of the service. The service-specific module

"glues" the standard modules to the PWE3 MIB modules.

The next layer of the PWE3 MIB structure is the PW MIB module

[RFC5601]. This module is used to configure general parameters of

PWs that are common to all types of emulated services and PSNs. This layer is connected to the service-specific layer above and the PSN

layer below.

The PSN layer provides PSN-specific modules for each type of PSN.

These modules associate the PW with one or more "tunnels" that carry the service over the PSN. These modules are used to "glue" the PW

service to the underlying PSN-specific MIB modules. This document

defines the MIB module for PW over MPLS PSN.

[RFC5542] defines some of the object types used in these modules.

5. Features Checklist

The PW-MPLS-STD-MIB module is designed to satisfy the following

requirements and constraints:

- The MIB module supports both manually configured and signaled PWs. - The MIB module supports point-to-point PW connections.

- The MIB module enables the use of any emulated service.

- The MIB module supports MPLS-TE outer tunnel, non-TE MPLS outer

tunnel (an outer tunnel signaled by LDP or set up manually), and

no outer tunnel (where the PW label is the only label in the MPLS stack). The latter case is applicable for manual configuration of PW over a single hop, as for signaled MPLS PSN even across a

single hop there is an MPLS tunnel -- even though the actual

packet may not contain the MPLS tunnel label due to PHP.

The MIB module uses Textual Conventions (TCs) from [RFC2578],

[RFC2579], [RFC2580], [RFC2863], [RFC3811], [RFC3813], [RFC5542], and [RFC5601].

Zelig & Nadeau Standards Track [Page 4]

6. MIB Module Usage

- The PW table (pwTable) in [RFC5601] is used for all PW types (ATM, FR, Ethernet, SONET, etc.). This table contains high-level

generic parameters related to the PW creation. The operator or

the agent creates a row for each PW.

- If the selected PSN type in the pwTable is MPLS, the agent creates a row in the MPLS-specific parameters table (pwMplsTable) in this module, which contains MPLS-specific parameters such as EXP bits

handling and outer tunnel configuration.

- The operator configures the association to the desired MPLS tunnel (required for MPLS-TE tunnels or for manually configured PWs)

through the pwMplsTeOutboundTable. For the LDP-based outer

tunnel, there is no need for manual configuration since there is

only a single tunnel toward the peer.

- The agent creates rows in the MPLS mapping table in order to allow quick retrieval of information based on the tunnel indexes.

The relation to the MPLS network is by configuration of the edge LSR only -- i.e., the LSR that provides the PW function. Since tunnels

are unidirectional, a pair of tunnels MUST exist (one for inbound,

one for outbound). Figure 1 depicts a PW that originates and

terminates at LSR-M. It uses tunnels A and B formed by cross-

connects (XCs) Ax and Bx continuing through LSR-N to LSR-P. The

concatenations of XCs create the tunnels. Note: ’X’ denotes a

tunnel’s cross-connect.

Zelig & Nadeau Standards Track [Page 5]

Tunnel A

<- - - - - - - - - - - - - - - - - - - - - - - - - - - -

+---- (edge) LSR-M ---+ +--------- LSR-N ---------+ + LSR-P

|---+ | | | |

| | XC | | XC | |

+ | A1 (M<-N) +----+ +----+ A2 (M<-P) +----+ +----+

| | <------| | | |<--------------| | | |

<-->| N |PWin inSeg |MPLS| |MPLS| outSeg inSeg |MPLS| |MPLS|

N S | | <---X<-----| IF | | IF |<------X<------| IF | | IF |

A E | S | | |<-->| | | |<-->| | |

T R | | --->X----->| | | |------>X------>| | | |

I V | P |PWout outSeg| | | | inSeg outSeg | | | |

V I | | ------>| | | |-------------->| | | |

E C + | XC +----+ +----+ XC +----+ +----+

E |---+ B1 (M->N) | | B2 (M->P) | |

| | | | |

+---------------------+ +-------------------------+ +-----

- - - - - - - - - - - - - - - - - - - - - - - - - - - ->

Tunnel B

Figure 1: PW modeling over MPLS

The PW-MPLS-STD-MIB supports three options for an MPLS network:

(1) In the MPLS-TE case, tunnels A and B are created via the MPLS-

TE-STD-MIB [RFC3812]. The tunnels are associated (in each peer independently) to the PW by the four indexes that uniquely

identify the tunnel at the MPLS-TE-STD-MIB.

(2) In the non-TE case, tunnels A1 and B1 are either manually

configured or set up with LDP. The tunnels are associated to

the PW by the XC index in the MPLS-LSR-STD-MIB [RFC3813].

(3) In the PW-label-only case, there is no outer tunnel on top of

the PW label. This case is useful in the case of adjacent

Provider Edges (PEs) in manual configuration mode. Note that

for signaled tunnels, when LSR-N acts as PHP for the outer

tunnel label, there are still entries for the outer tunnel in

the relevant MPLS MIB modules, so even for the case of adjacent LSRs, the relevant mode is either MPLS-TE or non-TE.

A combination of MPLS-TE outer tunnel(s) and LDP outer tunnel for the same PW is allowed through the pwMplsOutboundTunnel. The current

tunnel that is used to forward traffic is indicated in the object

pwMplsOutboundTunnelTypeInUse.

Zelig & Nadeau Standards Track [Page 6]

The PW-MPLS-STD-MIB module reports through the inbound table the XC

entry in the LDP-STD-MIB [RFC3815] of the PW that was signaled

through LDP.

This MIB module assumes that a PW can be associated to one MPLS-TE

tunnel at a time. This tunnel may be composed of multiple instances (i.e., LSP), each represented by a separate instance index. The

selection of the active LSP out of the possible LSPs in the tunnel is out of the scope of this MIB module as it is part of the MPLS PSN

functionality. The current active LSP is reported through this MIB

module.

It is important to note that inbound (tunnel originated in the remote PE) mapping is not configured or reported through the PW-MPLS-STD-

MIB module since the local PE does not know the inbound association

between specific PW and MPLS tunnels.

7. PW-MPLS-STD-MIB Example

The following example (supplement the example provided in [RFC5601]) assumes that the node has already established the LDP tunnel to the

peer node and that a PW has been configured in the pwTable in

[RFC5601] with pwPsnType equal ’mpls’.

The agent creates an entry in pwMplsTable with the following

parameters:

pwMplsMplsType mplsNonTe(1), -- LDP tunnel

pwMplsExpBitsMode outerTunnel(1), -- Default

pwMplsExpBits 0, -- Default

pwMplsTtl 2, -- Default

pwMplsLocalLdpID 192.0.2.200:0,

pwMplsLocalLdpEntityIndex 1,

pwMplsPeerLdpID 192.0.2.5:0,

pwMplsStorageType nonVolatile(3)

The agent also creates an entry in pwMplsOutboundTable for reporting the mapping of the PW on the LDP tunnel:

pwMplsOutboundLsrXcIndex 100, - The XC number for the -- LDP tunnel

pwMplsOutboundTunnelIndex 0, -- No TE tunnel

pwMplsOutboundTunnelInstance 0, -- No TE tunnel

pwMplsOutboundTunnelLclLSR 0, -- No TE tunnel

pwMplsOutboundTunnelPeerLSR 0, -- No TE tunnel

pwMplsOutboundIfIndex 0, -- Not applicable

pwMplsOutboundTunnelTypeInUse mplsNonTe(3)

Zelig & Nadeau Standards Track [Page 7]

The agent now creates entries for the PW in the following

tables:

- pwMplsInboundTable

- pwMplsNonTeMappingTable (2 entries)

To create an MPLS-TE tunnel to carry this PW, the operator

takes the following steps:

- Set pwMplsMplsType in pwMplsTable to both mplsNonTe(1) and

mplsTe(0).

- Set pwMplsOutboundTunnelIndex, pwMplsOutboundTunnelInstance,

pwMplsOutboundTunnelLclLSR, and pwMplsOutboundTunnelPeerLSR in

pwMplsOutboundTable to the MPLS-TE tunnel that will carry this PW. The agent will report the tunnel that the PW is currently using

through pwMplsOutboundTunnelTypeInUse, and will report the PW to

MPLS-TE tunnel/LSP mapping in pwMplsTeMappingTable.

8. Object Definitions

PW-MPLS-STD-MIB DEFINITIONS ::= BEGIN

IMPORTS

MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2

FROM SNMPv2-SMI -- [RFC2578]

MODULE-COMPLIANCE, OBJECT-GROUP

FROM SNMPv2-CONF -- [RFC2580]

StorageType

FROM SNMPv2-TC -- [RFC2579]

InterfaceIndexOrZero

FROM IF-MIB -- [RFC2863]

MplsTunnelIndex, MplsTunnelInstanceIndex,

MplsLdpIdentifier, MplsLsrIdentifier

FROM MPLS-TC-STD-MIB -- [RFC3811]

MplsIndexType

FROM MPLS-LSR-STD-MIB -- [RFC3813]

PwIndexType

FROM PW-TC-STD-MIB -- [RFC5542]

Zelig & Nadeau Standards Track [Page 8]

pwIndex -- [RFC5601]

FROM PW-STD-MIB

;

pwMplsStdMIB MODULE-IDENTITY

LAST-UPDATED "200906120000Z" -- 12 June 2009 00:00:00 GMT

ORGANIZATION "Pseudowire Emulation Edge-to-Edge (PWE3) Working

Group."

CONTACT-INFO

"

David Zelig, Editor

Email: davidz@https://www.wendangku.net/doc/0a15583075.html,

Thomas D. Nadeau, Editor

Email: tom.nadeau@https://www.wendangku.net/doc/0a15583075.html,

The PWE3 Working Group (email distribution pwe3@https://www.wendangku.net/doc/0a15583075.html,,

https://www.wendangku.net/doc/0a15583075.html,/html.charters/pwe3-charter.html)

"

DESCRIPTION

"This MIB module complements the PW-STD-MIB module for PW

operation over MPLS.

Copyright (c) 2009 IETF Trust and the persons identified as

authors of the code. All rights reserved.

Redistribution and use in source and binary forms, with or

without modification, are permitted provided that the

following conditions are met:

- Redistributions of source code must retain the above

copyright notice, this list of conditions and the

following disclaimer.

- Redistributions in binary form must reproduce the above

copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials

provided with the distribution.

- Neither the name of Internet Society, IETF or IETF Trust,

nor the names of specific contributors, may be used to

endorse or promote products derived from this software

without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND

CONTRIBUTORS ’AS IS’ AND ANY EXPRESS OR IMPLIED WARRANTIES,

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE

Zelig & Nadeau Standards Track [Page 9]

DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR

CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)

HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN

CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5602;

see the RFC itself for full legal notices.

"

-- Revision history.

REVISION "200906120000Z" -- 12 June 2009 00:00:00 GMT

DESCRIPTION

"First published as RFC 5602. "

::= { mib-2 181 }

-- Top-level components of this MIB.

-- Notifications

pwMplsNotifications OBJECT IDENTIFIER

::= { pwMplsStdMIB 0 }

-- Tables, Scalars

pwMplsObjects OBJECT IDENTIFIER

::= { pwMplsStdMIB 1 }

-- Conformance

pwMplsConformance OBJECT IDENTIFIER

::= { pwMplsStdMIB 2 }

-- PW MPLS table

pwMplsTable OBJECT-TYPE

SYNTAX SEQUENCE OF PwMplsEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"This table controls MPLS-specific parameters when the PW is

going to be carried over MPLS PSN."

::= { pwMplsObjects 1 }

pwMplsEntry OBJECT-TYPE

SYNTAX PwMplsEntry

MAX-ACCESS not-accessible

Zelig & Nadeau Standards Track [Page 10]

STATUS current

DESCRIPTION

"A row in this table represents parameters specific to MPLS

PSN for a pseudowire (PW). The row is created

automatically by the local agent if the pwPsnType is

mpls(1). It is indexed by pwIndex, which uniquely

identifies a singular PW.

Manual entries in this table SHOULD be preserved after a

reboot, and the agent MUST ensure the integrity of those

entries.

If the set of entries of a specific row were found to be

nonconsistent after reboot, the PW pwOperStatus MUST be

declared as down(2).

Any read-write object in this table MAY be changed at any

time; however, change of some objects (for example,

pwMplsMplsType) during PW forwarding state MAY cause traffic disruption."

INDEX { pwIndex }

::= { pwMplsTable 1 }

PwMplsEntry ::= SEQUENCE {

pwMplsMplsType BITS,

pwMplsExpBitsMode INTEGER,

pwMplsExpBits Unsigned32,

pwMplsTtl Unsigned32,

pwMplsLocalLdpID MplsLdpIdentifier,

pwMplsLocalLdpEntityIndex Unsigned32,

pwMplsPeerLdpID MplsLdpIdentifier,

pwMplsStorageType StorageType

}

pwMplsMplsType OBJECT-TYPE

SYNTAX BITS {

mplsTe (0),

mplsNonTe (1),

pwOnly (2)

}

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This object is set by the operator to indicate the outer

tunnel types, if existing. mplsTe(0) is used if the outer

tunnel is set up by MPLS-TE, and mplsNonTe(1) is used if the outer tunnel is set up by LDP or manually. A combination of mplsTe(0) and mplsNonTe(1) MAY exist.

pwOnly(2) is used if there is no outer tunnel label, i.e., Zelig & Nadeau Standards Track [Page 11]

in static provisioning without an MPLS tunnel. pwOnly(2)

cannot be combined with mplsNonTe(1) or mplsTe(0).

An implementation that can identify automatically that the

peer node is directly connected MAY support the bit

pwOnly(2) as read-only.

"

DEFVAL { { mplsNonTe } }

::= { pwMplsEntry 1 }

pwMplsExpBitsMode OBJECT-TYPE

SYNTAX INTEGER {

outerTunnel (1),

specifiedValue (2),

serviceDependant (3)

}

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This object is set by the operator to determine the PW shim

label EXP bits. The value of outerTunnel(1) is used where

there is an outer tunnel -- pwMplsMplsType equals to

mplsTe(0) or mplsNonTe(1). Note that in this case, there

is no need to mark the PW label with the EXP bits, since the PW label is not visible to the intermediate nodes.

If there is no outer tunnel, specifiedValue(2) SHOULD be used to indicate that the value is specified by pwMplsExpBits.

Setting serviceDependant(3) indicates that the EXP bits are

set based on a rule that is implementation specific."

DEFVAL { outerTunnel }

::= { pwMplsEntry 2 }

pwMplsExpBits OBJECT-TYPE

SYNTAX Unsigned32 (0..7)

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This object is set by the operator if pwMplsExpBitsMode is

set to specifiedValue(2) to indicate the MPLS EXP bits to

be used on the PW shim label. Otherwise, it SHOULD be set

to zero."

DEFVAL { 0 }

::= { pwMplsEntry 3 }

pwMplsTtl OBJECT-TYPE

SYNTAX Unsigned32 (0..255)

MAX-ACCESS read-write

Zelig & Nadeau Standards Track [Page 12]

STATUS current

DESCRIPTION

"This object is set by the operator to indicate the PW TTL

value to be used on the PW shim label."

DEFVAL { 2 }

::= { pwMplsEntry 4 }

pwMplsLocalLdpID OBJECT-TYPE

SYNTAX MplsLdpIdentifier

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"The LDP identifier of the LDP entity that creates

this PW in the local node. As the PW labels are always

set from the per-platform label space, the last two octets

in the LDP ID MUST always both be zeros."

REFERENCE

"’LDP specifications’, RFC 3036, section 2.2.2."

::= { pwMplsEntry 5 }

pwMplsLocalLdpEntityIndex OBJECT-TYPE

SYNTAX Unsigned32 (1..4294967295)

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"The local node LDP Entity Index of the LDP entity creating

this PW."

::= { pwMplsEntry 6 }

pwMplsPeerLdpID OBJECT-TYPE

SYNTAX MplsLdpIdentifier

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The peer LDP identifier of the LDP session. This object

SHOULD return the value zero if LDP is not used or if the

value is not yet known."

::= { pwMplsEntry 7 }

pwMplsStorageType OBJECT-TYPE

SYNTAX StorageType

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This variable indicates the storage type for this row."

DEFVAL { nonVolatile }

::= { pwMplsEntry 8 }

Zelig & Nadeau Standards Track [Page 13]

-- End of PW MPLS Table

-- Pseudowire MPLS Outbound Tunnel Table

pwMplsOutboundTable OBJECT-TYPE

SYNTAX SEQUENCE OF PwMplsOutboundEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"This table reports and configures the current outbound MPLS

tunnels (i.e., toward the PSN) or the physical interface in

the case of a PW label only that carries the PW traffic. It also reports the current outer tunnel and LSP that forward

the PW traffic."

::= { pwMplsObjects 2 }

pwMplsOutboundEntry OBJECT-TYPE

SYNTAX PwMplsOutboundEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"A row in this table configures the outer tunnel used for

carrying the PW traffic toward the PSN.

In the case of PW label only, it configures the interface

that will carry the PW traffic.

An entry in this table augments the pwMplsEntry, and is

created automatically when the corresponding row has been

created by the agent in the pwMplsEntry.

This table points to the appropriate MPLS MIB module:

In the MPLS-TE case, the three objects relevant to the

indexing of a TE tunnel head-end (as used in the

MPLS-TE-STD-MIB) are to be configured, and the tunnel

instance indicates the LSP that is currently in use for

forwarding the traffic.

In the case of signaled non-TE MPLS (an outer tunnel label

assigned by LDP), the table points to the XC entry in the

LSR-STD-MIB. If the non-TE MPLS tunnel is manually

configured, the operator configures the XC pointer to this

tunnel.

In the case of PW label only (no outer tunnel), the ifIndex

of the port to carry the PW is configured here.

Zelig & Nadeau Standards Track [Page 14]

It is possible to associate a PW to one TE tunnel head-end

and a non-TE tunnel together. An indication in this table

will report the currently active one. In addition, in the

TE case, the table reports the active tunnel instance

(i.e., the specific LSP in use).

Any read-write object in this table MAY be changed at any

time; however, change of some objects (for example,

MPLS-TE indexes) during PW forwarding state MAY cause traffic disruption."

AUGMENTS { pwMplsEntry }

::= { pwMplsOutboundTable 1 }

PwMplsOutboundEntry ::= SEQUENCE {

pwMplsOutboundLsrXcIndex MplsIndexType,

pwMplsOutboundTunnelIndex MplsTunnelIndex,

pwMplsOutboundTunnelInstance MplsTunnelInstanceIndex,

pwMplsOutboundTunnelLclLSR MplsLsrIdentifier,

pwMplsOutboundTunnelPeerLSR MplsLsrIdentifier,

pwMplsOutboundIfIndex InterfaceIndexOrZero,

pwMplsOutboundTunnelTypeInUse INTEGER

}

pwMplsOutboundLsrXcIndex OBJECT-TYPE

SYNTAX MplsIndexType

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This object is applicable if the pwMplsMplsType mplsNonTe(1) bit is set, and MUST return a value of zero otherwise.

If the outer tunnel is signaled, the object is read-only

and indicates the XC index in the MPLS-LSR-STD-MIB of the

outer tunnel toward the peer. Otherwise (tunnel is set up

manually), the operator defines the XC index of the manually created outer tunnel through this object.

"

::= { pwMplsOutboundEntry 1 }

pwMplsOutboundTunnelIndex OBJECT-TYPE

SYNTAX MplsTunnelIndex

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This object is applicable if the pwMplsMplsType mplsTe(0)

bit is set, and MUST return a value of zero otherwise.

It is part of the set of indexes for the outbound tunnel. Zelig & Nadeau Standards Track [Page 15]

The operator sets this object to represent the desired

tunnel head-end toward the peer for carrying the PW

traffic.

"

::= { pwMplsOutboundEntry 2 }

pwMplsOutboundTunnelInstance OBJECT-TYPE

SYNTAX MplsTunnelInstanceIndex

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"This object is applicable if the pwMplsMplsType mplsTe(0)

bit is set, and MUST return a value of zero otherwise.

It indicates the actual tunnel instance that is currently

active and carrying the PW traffic. It SHOULD return the

value zero if the information from the MPLS-TE

application is not yet known.

"

::= { pwMplsOutboundEntry 3 }

pwMplsOutboundTunnelLclLSR OBJECT-TYPE

SYNTAX MplsLsrIdentifier

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This object is applicable if the pwMplsMplsType mplsTe(0)

bit is set, and MUST return a value of all zeros otherwise.

It is part of the set of indexes for the outbound tunnel.

The operator sets this object to represent the desired

tunnel head-end toward the peer for carrying the PW

traffic.

"

::= { pwMplsOutboundEntry 4 }

pwMplsOutboundTunnelPeerLSR OBJECT-TYPE

SYNTAX MplsLsrIdentifier

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This object is applicable if the pwMplsMplsType mplsTe(0)

bit is set, and MUST return a value of zero otherwise.

It is part of the set of indexes for the outbound tunnel.

Note that in most cases, it equals to pwPeerAddr.

"

::= { pwMplsOutboundEntry 5 }

pwMplsOutboundIfIndex OBJECT-TYPE

SYNTAX InterfaceIndexOrZero

Zelig & Nadeau Standards Track [Page 16]

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"This object is applicable if the pwMplsMplsType pwOnly(0)

bit is set, and MUST return a value of zero otherwise.

The operator configures the ifIndex of the outbound port

in this case.

"

::= { pwMplsOutboundEntry 6 }

pwMplsOutboundTunnelTypeInUse OBJECT-TYPE

SYNTAX INTEGER {

notYetKnown (1),

mplsTe (2),

mplsNonTe (3),

pwOnly (4)

}

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"This object indicates the current tunnel that is carrying

the PW traffic.

The value of notYetKnown(1) should be used if the agent is

currently unable to determine which tunnel or interface is

carrying the PW, for example, because both tunnels are in

operational status down.

"

::= { pwMplsOutboundEntry 7 }

-- End of PW MPLS Outbound Tunnel table

-- PW MPLS inbound table

pwMplsInboundTable OBJECT-TYPE

SYNTAX SEQUENCE OF PwMplsInboundEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"This table indicates the PW LDP XC entry in the

MPLS-LSR-STD-MIB for signaled PWs.

"

::= { pwMplsObjects 3 }

pwMplsInboundEntry OBJECT-TYPE

SYNTAX PwMplsInboundEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

Zelig & Nadeau Standards Track [Page 17]

"A row in this table is created by the agent

for each signaled PW, and shows the XC index related to

the PW signaling in the inbound direction in the

MPLS-LSR-STD-MIB that controls and display the information

for all the LDP signaling processes in the local node.

"

INDEX { pwIndex }

::= { pwMplsInboundTable 1 }

PwMplsInboundEntry ::= SEQUENCE {

pwMplsInboundXcIndex MplsIndexType

}

pwMplsInboundXcIndex OBJECT-TYPE

SYNTAX MplsIndexType

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The XC index representing this PW in the inbound

direction. It MUST return the value zero if the

information is not yet known."

::= { pwMplsInboundEntry 1 }

-- End of PW MPLS inbound table

-- PW to Non-TE mapping Table.

pwMplsNonTeMappingTable OBJECT-TYPE

SYNTAX SEQUENCE OF PwMplsNonTeMappingEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"This table indicates the PW association to the outbound

tunnel in non-TE applications, maps the PW to its (inbound)

XC entry, and indicates the PW-to-physical interface mapping for a PW without an outer tunnel.

"

::= { pwMplsObjects 4 }

pwMplsNonTeMappingEntry OBJECT-TYPE

SYNTAX PwMplsNonTeMappingEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"A row in this table displays the association

between the PW and

- its non-TE MPLS outbound outer tunnel,

Zelig & Nadeau Standards Track [Page 18]

- its XC entry in the MPLS-LSR-STD-MIB, or

- its physical interface if there is no outer tunnel

(PW label only) and manual configuration.

Rows are created in this table by the agent depending on

the setting of pwMplsMplsType:

- If the pwMplsMplsType mplsNonTe(1) bit is set, the agent

creates a row for the outbound direction

(pwMplsNonTeMappingDirection set to psnBound(1)).

The pwMplsNonTeMappingXcIndex holds the XC index in the

MPLS-LSR-STD-MIB of the PSN-bound outer tunnel.

pwMplsNonTeMappingIfIndex MUST be zero for this row.

- If the pwMplsMplsType pwOnly(2) bit is set, the agent

creates a row for the outbound direction

(pwMplsNonTeMappingDirection set to psnBound(1)).

The pwMplsNonTeMappingIfIndex holds the ifIndex of the

physical port this PW will use in the outbound direction.

pwMplsNonTeMappingXcIndex MUST be zero for this row.

- If the PW has been set up by a signaling protocol (i.e.,

pwOwner equal pwIdFecSignaling(2) or

genFecSignaling(3)), the agent creates a row for the

inbound direction (pwMplsNonTeMappingDirection set to

fromPsn(2)).

The pwMplsNonTeMappingXcIndex holds the XC index in the

MPLS-LSR-STD-MIB of the PW LDP-generated XC entry.

pwMplsNonTeMappingIfIndex MUST be zero for this row.

An application can use this table to quickly retrieve the

PW carried over specific non-TE MPLS outer tunnel or

physical interface.

"

INDEX { pwMplsNonTeMappingDirection,

pwMplsNonTeMappingXcIndex,

pwMplsNonTeMappingIfIndex,

pwMplsNonTeMappingPwIndex }

::= { pwMplsNonTeMappingTable 1 }

PwMplsNonTeMappingEntry ::= SEQUENCE {

pwMplsNonTeMappingDirection INTEGER,

pwMplsNonTeMappingXcIndex MplsIndexType,

pwMplsNonTeMappingIfIndex InterfaceIndexOrZero,

pwMplsNonTeMappingPwIndex PwIndexType

}

Zelig & Nadeau Standards Track [Page 19]

pwMplsNonTeMappingDirection OBJECT-TYPE

SYNTAX INTEGER {

psnBound (1),

fromPsn (2)

}

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"Index for the conceptual XC row identifying the tunnel-to-PW mappings, indicating the direction of the packet flow for

this entry.

psnBound(1) indicates that the entry is related to

packets toward the PSN.

fromPsn(2) indicates that the entry is related to

packets coming from the PSN.

"

::= { pwMplsNonTeMappingEntry 1 }

pwMplsNonTeMappingXcIndex OBJECT-TYPE

SYNTAX MplsIndexType

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"See the description clause of pwMplsNonTeMappingEntry for

the usage guidelines of this object."

::= { pwMplsNonTeMappingEntry 2 }

pwMplsNonTeMappingIfIndex OBJECT-TYPE

SYNTAX InterfaceIndexOrZero

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"See the description clause of pwMplsNonTeMappingEntry for

the usage guidelines of this object."

::= { pwMplsNonTeMappingEntry 3 }

pwMplsNonTeMappingPwIndex OBJECT-TYPE

SYNTAX PwIndexType

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The value that represents the PW in the pwTable."

::= { pwMplsNonTeMappingEntry 4 }

-- End of PW to Non-TE mapping Table.

-- PW to TE MPLS tunnels mapping Table.

Zelig & Nadeau Standards Track [Page 20]

高铁接触网零件名称及用途

高速铁路接触网零件讲义 一、培训方式 采用现场讲解,讲义课件和学员现场实际操作的方法 二、培训对象 所有电力和接触网专业的学员 三、培训要求 参加培训的人员能正确说出材料的名称和用途 四、培训讲义 (一)腕臂系统 1、单槽承力索座 用途:安装在平腕臂上悬挂承力索。 1、双槽承力索座 用途:安装在中心锚结支柱的平腕臂上悬挂承力索和固定中锚辅助绳。 2、腕臂(定位管)支撑 用途:本零件适用于在平、斜腕臂(斜腕臂、定位管)之间的加强连接。 3、定位环 ?用途:安装在斜腕臂及定位管中连接定位器或连接其它带钩头零件。4、锚支定位卡子 用途:安装在转换柱非工作支定位管上固定非工作支接触线。 5、套管双耳 用途:安装在平腕臂上连接斜腕臂。 6、支撑管卡子

?用途:安装在腕臂和定位管上固定耳环类零件(支撑管)。 (二)定位装置 1、矩形定位器 用途:安装在直线区段或R>800m曲线段腕臂柱上通过定位线夹固定接触线。 2、定位支座 用途:安装在定位管上钩挂定位器。 3、定位线夹 用途:安装在定位器上固定接触线。 (三)下锚补偿装置 1、接触线棘轮补偿装置 ?用途:本装置用于接触网下锚处调整导线张力。 2、承力索棘轮补偿装置 用途:本装置用于接触网下锚处调整导线张力。 3、接触线终端锚固线夹 ?用途:安装于铜合金或铜接触线终端锚固处。 4、承力索终端锚固线夹 用途:安装于线型为(TJ95-127)承力索终端锚固使用。 5、接触线终端锚固线夹 6、倒装耐张线夹:NLD-4 用途:用于185mm2或240mm2铝绞线或钢芯铝绞线下锚。安装时铝绞线上应缠铝包带。 (四)悬吊零件

1、整体吊弦 用途:安装在承力索上悬吊接触线。 2、接触线吊弦线夹 用途:安装在接触线上连接吊弦悬挂接触线 3、承力索吊弦线夹 用途:安装在承力索上连接吊弦悬挂接触线。 4、杵座鞍子 用途:与杵头形零件连接悬挂金属绞线。 5、钩头鞍子 用途:与带口单耳零件连接悬挂金属绞线。 6、双耳鞍子 用途:与单耳零件连接悬挂金属绞线。 7、悬垂线夹 用途:用于与单耳环件连接悬挂金属绞线。 (五)中心锚结装置 1、接触线中心锚结线夹 用途:安装在接触线上与中锚绳连接,防止整个锚段向一侧窜动或接触悬挂断线时缩小事故范围。 2、承力索中心锚结线夹 用途:安装在承力索上固定中锚绳或中锚辅助绳,防止整个锚段向一侧窜动或接触悬挂断线时缩小事故范围。 (六)电连接装置

高速铁路接触网精测精修实施办法

高速铁路接触网精测精修实施办法讲义 在中国高速铁路快速发展的今天,我国通过几年高速铁路的运行总结的基础上,总公司运输局从2016年9月1日起开始施行铁总运(2015)363号,为中国高速铁路的检修模式开始新的探讨。下面根据363号文件一起学习。本办法共分8章,内容主要在前7章,37条。 第一章总则 第一条为加强高速铁路接触网性能和状态管理,规范高速铁路接触网精测精修工作,确保高速铁路接触网运行安全,在总结高速铁路接触网运营规律的基础上,依据《高速铁路接触网运行维修规则》,制定本办法。 第二条接触网精测精修是指通过检测动态条件下的弓网作用参数,测量静态条件下的接触网几何位置,检验零部件质量状态,依据检测、检验分析结果,全面调整接触网静态几何参数、更换失效或接近预期寿命的零部件和设备、更换局部磨耗接近限界的接触导线,恢复接触网标准状态。 接触网精测精修包括精确检测、零部件检验、分析诊断与设计、精确修理、验收等工作。 第三条标准状态资料至少包括相关设计文件、接触网平面竣工图、“一杆一档”数据和非接触测量的完整数据(含波形图)以及接触网零部件预期寿命状态等资料。 第四条接触网精测精修工作应参照《铁路技术管理规程(高速铁路部分)》《高速铁路电力牵引供电工程施工技术规程》《高速铁路电力牵引供电工程施工质量验收标准》《高速铁路工程动态验收技术规范》《铁路营业线施工安全管理办法》等文件执行。 第五条本办法适用于200km/h及以上的铁路和200km/h以下仅运行

动车组列车的铁路。 第二章一般规定 第六条正常情况下,一般运行7年或弓架次达到50万次以上应安排进行一次精测精修。 遇有动态检测发现弓网动态作用特性成区段持续不良;接触网超标值增多或故障多发且分析后认为有必要实施精测精修,以及线路纵断面发生调整的区段,应在规定时间内提报精测精修计划。 第七条接触网精测精修工作执行铁路营运线施工有关规定,安排在天窗时间内进行,接触网精测精修天窗时间一般不少于4小时,一个任务周期内,天窗日计划原则上应逐日安排连续进行。 第八条铁路总公司监督、检查、指导全路高速铁路接触网精测精修实施情况。各铁路局负责编制接触网精测精修计划,组织审批设计和实施方案,组织实施和竣工验收。 第三章精确检测 第九条接触网精确检测和分析工作一般应由具有高速铁路接触网综合检测设备、具备高速铁路接触网检测数据和设备质量分析诊断能力的专业单位承担,如需要外部单位承担,应通过公开招标方式选择有相应业绩的专业单位。 第十条精确检测一般由综合检测列车、高铁接触网检测车或者其他能够完成精确检测任务的设备实施。精测设备应经过标定且在合格的周期内,通过精测前的现场测试验证,满足精度要求。 第十一条精确检测一般采用非接触检测和接触检测两种方式。非接触检测主要用于测量接触网几何位置。接触检测主要用于测量弓网动态性能参数。 第十二条动态检测可结合综合检测车检测工作周期统筹安排。根据

铁路接触网组成及分类

接触网的组成 接触网是沿铁路上空架设的一条特殊形式的输电线路,它由接触 悬挂、支持装置、定位装置、支柱与基础等几部分组成,如图1-1-1所示。 按鞘匡垂或 1—支桂2-S式绽躲子壬毛皆4—歆力案 5—按3 走宦茅亍一吊冠S —定垃當支議 9一走垃管■.疾育11 一钢轨 1?支持装置 支持装置是接触网中支持接触悬挂,并将其机械负荷传给支柱固定的部分。支持装置包括腕臂、平腕臂(或水平拉杆、悬式绝缘子串)、棒式绝缘子及接触悬挂的悬吊零件。根据接触网所在区间、站场和大型建筑物需要的不同,支持装置表现为不同的形式,女口:腕臂结构(图1 —1—1所示为区间腕臂装配形式)、软横跨、硬横跨(多股道站场使用)及隧道、桥梁和其它大型建筑物上的特殊支持结构。

2.定位装置 定位装置包括定位管、定位器、定位线夹及其连接零件。其作用是固定接触线的横向位置,使接触线水平定位在受电弓滑板运行轨迹范围内,保证接触线与受电弓不脱离,使受电弓磨耗均匀,同时将接触线的水平负荷传给支柱。 3.支柱与基础支柱与基础用以承受接触悬挂、支持和定位装置的全部负荷,并将接触悬挂固定在规定的位置和高度上。我国接触网中主要采用预应力钢筋混凝土支柱和钢柱。基础用来承载支柱负荷,即将支柱固定在地下用钢筋混凝土制成的基础上,由基础承受支柱传给的全部负荷,并保证支柱的稳定性。预应力钢筋混凝土支柱可不设单独的基础,支柱直接埋入地下,起到基础的作用。

接触悬挂的类型 接触网的分类大多以接触悬挂的类型来区分。在一条接触网线路上,接触线和承力索在延伸一定长度后,为了满足供电和机械方面的要求,总是将接触网分成若干一定长度且相互独立的分段,这就是接触网的锚段。我们所讲的接触悬挂分类是针对架空式接触网中的每个锚段而言。根据其结构的不同分成简单接触悬挂和链形接触悬挂两大类。 1?简单接触悬挂 简单接触悬挂(以下简称简单悬挂)系由一根接触线直接固定在支柱支持装置上的悬挂形式。它在发展中经历了未补偿简单悬挂、季节调整式简单悬挂和目前采用的带补偿装置及弹性吊索式简单悬挂。其结构分别如图1 —2—1和图1 —2—2所示。 接触线(或承力索)端头同支柱的连接称为线索的下锚。下锚分两种方法,一是将线索端头同支柱直接固定连接,称为硬锚或者未补偿下锚。另一种是加装补偿装置,以调整线索的弛度和张力称为补偿下锚。 未补偿的简单悬挂结构简单,要求支柱高度较低,因此建设投资低,施工和检修方便。其缺点是导线的张力和弛度随气温的变化较大,接触线在悬挂点受力集中,形成硬点,弹性不均匀,不利于电力机车高速运行时取流。 近年来,国内外对简单悬挂做了不少研究和改进。我国现采用的带补偿装置及弹性吊索的简单悬挂系在接触线下锚处装设了张力补偿装置,以调节张力和弛度的变化。在悬挂处加装8?16m长的弹性吊索,通过弹性吊索悬挂接触线,增加了悬挂点减小了悬挂点处产生的硬点,改善了取流条件。另外跨距适当缩小,增大接触线张力的同时改善弛度对取流的影响。根据我国的试验,这种弹性简单悬挂在行车速度90kM/h时,弓线接触良好,取流正常,所以在多隧道的山区和行车速度不高的线路上可采用。我国在部分线

相关文档
相关文档 最新文档