Network Working Group                                   A. Fredette, Ed.
Request for Comments: 4209                             Hatteras Networks
Category: Standards Track                                   J. Lang, Ed.
                                                              Sonos Inc.
                                                            October 2005
        
Network Working Group                                   A. Fredette, Ed.
Request for Comments: 4209                             Hatteras Networks
Category: Standards Track                                   J. Lang, Ed.
                                                              Sonos Inc.
                                                            October 2005
        

Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems

密集波分复用(DWDM)光线路系统的链路管理协议(LMP)

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.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2005).

版权所有(C)互联网协会(2005年)。

Abstract

摘要

The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document.

链路管理协议(LMP)用于管理流量工程(TE)链路。在其当前形式中,LMP关注对等节点,即在信令和/或路由中对等的节点。本文档建议对LMP进行扩展,以允许在对等节点和相邻光线路系统(OLS)之间使用LMP。这些扩展旨在满足配套文件中描述的“光链路接口要求”。

1. Introduction
1. 介绍

Networks are being developed with routers, switches, optical cross-connects (OXCs), dense wavelength division multiplexing (DWDM) optical line systems (OLSes), and add-drop multiplexors (ADMs) that use a common control plane (e.g., Generalized MPLS (GMPLS)) to dynamically provision resources and to provide network survivability using protection and restoration techniques.

目前正在开发使用路由器、交换机、光交叉连接(OXC)、密集波分复用(DWDM)光线路系统(OLSE)和使用公共控制平面(例如,通用MPLS(GMPLS))的分插复用器(ADM)的网络使用保护和恢复技术动态提供资源并提供网络生存能力。

The Link Management Protocol (LMP) is being developed as part of the GMPLS protocol suite to manage traffic engineering (TE) links [RFC4204]. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing (e.g., OXC-to-OXC, as illustrated in Figure 1). In this document, extensions to LMP are proposed to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy

链路管理协议(LMP)是GMPLS协议套件的一部分,用于管理流量工程(TE)链路[RFC4204]。在其当前形式中,LMP关注对等节点,即在信令和/或路由中对等的节点(例如,如图1所示的OXC到OXC)。在本文档中,提出了LMP的扩展,以允许在对等节点和相邻光线路系统(OLS)之间使用LMP。这些扩展旨在满足

the "Optical Link Interface Requirements" described in [OLI]. It is assumed that the reader is familiar with LMP, as defined in [RFC4204].

[OLI]中描述的“光链路接口要求”。假设读者熟悉[RFC4204]中定义的LMP。

         +------+       +------+       +------+       +------+
         |      | ----- |      |       |      | ----- |      |
         | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
         |      | ----- |      |       |      | ----- |      |
         +------+       +------+       +------+       +------+
            ^                                             ^
            |                                             |
            +---------------------LMP---------------------+
        
         +------+       +------+       +------+       +------+
         |      | ----- |      |       |      | ----- |      |
         | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
         |      | ----- |      |       |      | ----- |      |
         +------+       +------+       +------+       +------+
            ^                                             ^
            |                                             |
            +---------------------LMP---------------------+
        

Figure 1: LMP Model

图1:LMP模型

Consider two peer nodes (e.g., two OXCs) interconnected by a wavelength-multiplexed link, i.e., a DWDM optical link (see Figure 1 above). Information about the configuration of this link and its current state is known by the two OLSes (OLS1 and OLS2). Allowing them to communicate this information to the corresponding peer nodes (OXC1 and OXC2) via LMP can improve network usability by reducing required manual configuration and by enhancing fault detection and recovery.

考虑由波长复用链路(即DWDM光链路)互连的两个对等节点(例如,两个OXC)(参见上面的图1)。两个OLSE(OLS1和OLS2)知道有关此链路的配置及其当前状态的信息。允许它们通过LMP将此信息传递给相应的对等节点(OXC1和OXC2),可以通过减少所需的手动配置和增强故障检测和恢复来提高网络可用性。

Information about the state of LSPs using the DWDM optical link is known by the peer nodes (OXC1 and OXC2), and allowing them to communicate this information to the corresponding OLSes (OLS1 and OLS2) is useful for alarm management and link monitoring. Alarm management is important because the administrative state of an LSP, known to the peer nodes (e.g., via the Admin Status object of GMPLS signaling [RFC3471]), can be used to suppress spurious alarm reporting from the OLSes.

对等节点(OXC1和OXC2)知道关于使用DWDM光链路的LSP的状态的信息,并且允许它们将该信息传送到相应的OLSE(OLS1和OLS2)对于报警管理和链路监控非常有用。报警管理很重要,因为对等节点(例如,通过GMPLS信令[RFC3471]的管理状态对象)已知的LSP管理状态可用于抑制来自OLSE的虚假报警报告。

The model for extending LMP to OLSes is shown in Figure 2.

将LMP扩展到OLSE的模型如图2所示。

         +------+       +------+       +------+       +------+
         |      | ----- |      |       |      | ----- |      |
         | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
         |      | ----- |      |       |      | ----- |      |
         +------+       +------+       +------+       +------+
           ^  ^             ^              ^             ^  ^
           |  |             |              |             |  |
           |  +-----LMP-----+              +-----LMP-----+  |
           |                                                |
           +----------------------LMP-----------------------+
        
         +------+       +------+       +------+       +------+
         |      | ----- |      |       |      | ----- |      |
         | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
         |      | ----- |      |       |      | ----- |      |
         +------+       +------+       +------+       +------+
           ^  ^             ^              ^             ^  ^
           |  |             |              |             |  |
           |  +-----LMP-----+              +-----LMP-----+  |
           |                                                |
           +----------------------LMP-----------------------+
        

Figure 2: Extended LMP Model

图2:扩展LMP模型

In this model, a peer node may have LMP sessions with adjacent OLSes, as well as adjacent peer nodes. In Figure 2, for example, the OXC1- OXC2 LMP session can be used to build traffic-engineering (TE) links for GMPLS signaling and routing, as described in [RFC4204]. The OXC1-OLS1 and the OXC2-OLS2 LMP sessions are used to exchange information about the configuration of the DWDM optical link and its current state and information about the state of LSPs using that link.

在该模型中,对等节点可以具有与相邻olse以及相邻对等节点的LMP会话。例如,在图2中,OXC1-OXC2 LMP会话可用于为GMPLS信令和路由构建流量工程(TE)链路,如[RFC4204]中所述。OXC1-OLS1和OXC2-OLS2 LMP会话用于交换关于DWDM光链路的配置及其当前状态的信息以及关于使用该链路的LSP状态的信息。

The latter type of LMP sessions is discussed in this document. It is important to note that a peer node may have LMP sessions with one or more OLSes and an OLS may have LMP sessions with one or more peer nodes.

本文将讨论后一种类型的LMP会话。需要注意的是,对等节点可以具有与一个或多个OLS的LMP会话,并且OLS可以具有与一个或多个对等节点的LMP会话。

Although there are many similarities between an LMP session between two peer nodes and an LMP session between a peer node and an OLS, there are some differences as well. The former type of LMP session is used to provide the basis for GMPLS signaling and routing. The latter type of LMP session is used to augment knowledge about the links between peer nodes.

尽管两个对等节点之间的LMP会话与对等节点和OLS之间的LMP会话有许多相似之处,但也存在一些差异。前一种类型的LMP会话用于为GMPLS信令和路由提供基础。后一种类型的LMP会话用于增加关于对等节点之间链路的知识。

A peer node maintains its peer node-to-OLS LMP sessions and its peer node-to-peer node LMP sessions independently. This means that it MUST be possible for LMP sessions to come up in any order. In particular, it MUST be possible for a peer node-to-peer node LMP session to come up in the absence of any peer node-to-OLS LMP sessions, and vice versa.

对等节点独立地维护其对等节点到OLS LMP会话和其对等节点到对等节点LMP会话。这意味着LMP会话必须能够以任何顺序出现。特别是,对等节点到对等节点LMP会话必须能够在没有任何对等节点到OLS LMP会话的情况下出现,反之亦然。

1.1. Terminology
1.1. 术语

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

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

The reader is assumed to be familiar with the terminology in [RFC4204].

假定读者熟悉[RFC4204]中的术语。

DWDM: Dense wavelength division multiplexing

密集波分复用

OLS: Optical line system

光线路系统

Opaque:

不透明:

A device is called X-opaque if it examines or modifies the X aspect of the signal while forwarding an incoming signal from input to output.

如果设备在将输入信号从输入转发到输出时检查或修改信号的X方向,则称为X不透明。

OXC: Optical cross-connect

光交叉连接

Transparent:

透明的:

As defined in [RFC4204], a device is called X-transparent if it forwards incoming signals from input to output without examining or modifying the X aspect of the signal. For example, a Frame Relay switch is network-layer transparent; an all-optical switch is electrically transparent.

如[RFC4204]中所定义,如果设备将输入信号从输入转发到输出,而不检查或修改信号的X方向,则称为X透明设备。例如,帧中继交换机是网络层透明的;全光开关是电透明的。

1.2. Scope of LMP-WDM Protocol
1.2. LMP-WDM协议的范围

This document focuses on extensions required for use with opaque OLSes. In particular, this document is intended for use with OLSes having SONET, SDH, and Ethernet user ports.

本文档重点介绍与不透明OLSE一起使用所需的扩展。特别是,本文件旨在与具有SONET、SDH和以太网用户端口的OLSE一起使用。

At the time of this writing, work is ongoing in the area of fully transparent wavelength routing; however, it is premature to identify the necessary information to be exchanged between a peer node and an OLS in this context. Nevertheless, the protocol described in this document provides the necessary framework in which to exchange additional information that is deemed appropriate.

在撰写本文时,全透明波长路由领域的工作正在进行中;然而,在这种情况下,确定对等节点和OLS之间要交换的必要信息还为时过早。尽管如此,本文件中所述的协议提供了必要的框架,在该框架内,可交换被认为适当的其他信息。

2. LMP Extensions for Optical Line Systems
2. 光线路系统的LMP扩展

LMP currently consists of four main procedures, of which the first two are mandatory and the last two are optional:

LMP目前包括四个主要程序,其中前两个是强制性的,后两个是可选的:

1. Control channel management 2. Link property correlation 3. Link verification 4. Fault management

1. 控制通道管理2。链接属性相关性3。链接验证4。故障管理

All four functions are supported in LMP-WDM.

LMP-WDM支持所有四种功能。

2.1. Control Channel Management
2.1. 控制通道管理

As in [RFC4204], we do not specify the exact implementation of the control channel; it could be, for example, a separate wavelength, fiber, Ethernet link, an IP tunnel routed over a separate management network, a multi-hop IP network, or the overhead bytes of a data link.

与[RFC4204]一样,我们没有指定控制通道的确切实现;例如,它可以是单独的波长、光纤、以太网链路、通过单独的管理网络路由的IP隧道、多跳IP网络或数据链路的开销字节。

The control channel management for a peer node-to-OLS link is the same as for a peer node-to-peer node link, as described in [RFC4204].

对等节点到OLS链路的控制信道管理与对等节点到对等节点链路的控制信道管理相同,如[RFC4204]中所述。

To distinguish between a peer node-to-OLS LMP session and a peer node-to-peer node LMP session, a new LMP-WDM CONFIG object is defined (C-Type = 2). The format of the CONFIG object is as follows:

为了区分对等节点到OLS LMP会话和对等节点到对等节点LMP会话,定义了一个新的LMP-WDM配置对象(C-Type=2)。CONFIG对象的格式如下所示:

   Class = 6
        
   Class = 6
        

o C-Type = 2, LMP-WDM_CONFIG

o C-Type=2,LMP-WDM_配置

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |W|O|                      (Reserved)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |W|O|                      (Reserved)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The Reserved field should be sent as zero and ignored on receipt.

保留字段应作为零发送,并在收到时忽略。

WDM: 1 bit

波分复用:1位

This bit indicates support for the LMP-WDM extensions defined in this document.

此位表示支持本文档中定义的LMP-WDM扩展。

OLS: 1 bit

OLS:1位

If set, this bit indicates that the sender is an optical line system (OLS). If clear, this bit indicates that the sender is a peer node.

如果设置,此位表示发送方是光纤线路系统(OLS)。如果清除,此位表示发送方是对等节点。

The LMP-WDM extensions are designed for peer node-to-OLS LMP sessions. The OLS bit allows a node to identify itself as an OLS or a peer node. This is used to detect misconfiguration of a peer node-to-OLS LMP session between two peer nodes or a peer node-to-peer node LMP session between a peer node and an OLS.

LMP-WDM扩展是为对等节点到OLS LMP会话而设计的。OLS位允许节点将自己标识为OLS或对等节点。这用于检测两个对等节点之间的对等节点到OLS LMP会话或对等节点和OLS之间的对等节点到对等节点LMP会话的错误配置。

If the node does not support the LMP-WDM extensions, it MUST reply to the Config message with a ConfigNack message.

如果节点不支持LMP-WDM扩展,则必须使用ConfigNack消息回复配置消息。

If a peer node that is configured to run LMP-WDM receives a Config message with the OLS bit clear in LMP-WDM_CONFIG object, it MUST reply to the Config message with a ConfigNack message.

如果配置为运行LMP-WDM的对等节点在LMP-WDM_Config对象中接收到OLS位为clear的配置消息,则它必须使用ConfigNack消息回复配置消息。

2.2. Link Verification
2.2. 链接验证

The Test procedure used with OLSes is the same as described in [RFC4204]. The VerifyTransportMechanism (included in the BeginVerify and BeginVerifyAck messages) is used to allow nodes to negotiate a link verification method and is essential for line systems that have access to overhead bytes rather than the payload. The VerifyId (provided by the remote node in the BeginVerifyAck message and used in all subsequent Test messages) is used to differentiate Test messages from different LMP Link Verification procedures. In

与OLSE一起使用的测试程序与[RFC4204]中所述的相同。VerifyTransportMechanism(包含在BeginVerify和BeginVerifyAck消息中)用于允许节点协商链路验证方法,对于能够访问开销字节而不是有效负载的线路系统来说是必不可少的。VerifyId(由远程节点在BeginVerifyAck消息中提供,并在所有后续测试消息中使用)用于区分不同LMP链路验证过程中的测试消息。在里面

addition to the Test procedure described in [RFC4204], the trace monitoring function of [RFC4207] may be used for link verification when the OLS user ports are SONET or SDH.

除了[RFC4204]中描述的测试程序外,[RFC4207]的跟踪监控功能可用于OLS用户端口为SONET或SDH时的链路验证。

In a combined LMP and LMP-WDM context, there is an interplay between the data links being managed by peer node-to-peer node LMP sessions and peer node-to-OLS LMP sessions. For example, in Figure 2, the OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1, and the OXC2-OLS2 LMP session manages the data links between OXC2 and OLS2. However, the OXC1-OXC2 LMP session manages the data links between OXC1 and OXC2, which are actually a concatenation of the data links between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and the data links between OXC2 and OLS2. It is these concatenated links that comprise the TE links that are advertised in the GMPLS TE link state database.

在组合LMP和LMP-WDM上下文中,由对等节点到对等节点LMP会话和对等节点到OLS LMP会话管理的数据链路之间存在相互作用。例如,在图2中,OXC1-OLS1 LMP会话管理OXC1和OLS1之间的数据链路,OXC2-OLS2 LMP会话管理OXC2和OLS2之间的数据链路。然而,OXC1-OXC2 LMP会话管理OXC1和OXC2之间的数据链路,这实际上是OXC1和OLS1之间的数据链路、OLS1和OLS2之间的DWDM跨度以及OXC2和OLS2之间的数据链路的串联。正是这些连接的链路构成了在GMPLS TE链路状态数据库中公布的TE链路。

The implication of this is that when the data links between OXC1 and OXC2 are being verified, using the LMP link verification procedure, OLS1 and OLS2 need to make themselves transparent with respect to these concatenated data links. The coordination of verification of OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the responsibility of the peer nodes, OXC1 and OXC2.

这意味着,当使用LMP链路验证程序验证OXC1和OXC2之间的数据链路时,OLS1和OLS2需要使其自身对这些连接的数据链路透明。对等节点OXC1和OXC2负责协调OXC1-OLS1和OXC2-OLS2数据链路的验证,以确保这种透明度。

It is also necessary for these peer nodes to understand the mappings between the data links of the peer node - OLS LMP session and the concatenated data links of the peer node - peer node LMP session.

这些对等节点还需要了解对等节点-OLS LMP会话的数据链路与对等节点-对等节点LMP会话的串联数据链路之间的映射。

2.3. Link Summarization
2.3. 链接摘要

As in [RFC4204], the LinkSummary message is used to synchronize the Interface_Ids and correlate the properties of the TE link. (Note that the term "TE link" originated from routing/signaling applications of LMP, and this concept does not necessarily apply to an OLS. However, the term is used in this document to remain consistent with LMP terminology.) The LinkSummary message includes one or more DATA_LINK objects. The contents of the DATA_LINK object consist of a series of variable-length data items called Data Link sub-objects describing the capabilities of the data links.

与[RFC4204]中一样,LinkSummary消息用于同步接口ID并关联TE链路的属性。(请注意,“TE链路”一词起源于LMP的路由/信令应用,此概念不一定适用于OLS。然而,本文档中使用该术语是为了与LMP术语保持一致。)链路摘要消息包括一个或多个数据链路对象。数据链接对象的内容由一系列称为数据链接子对象的可变长度数据项组成,这些数据项描述了数据链接的功能。

In this document, several additional Data Link sub-objects are defined to describe additional link characteristics. The link characteristics are, in general, those needed by the CSPF to select the path for a particular LSP. These link characteristics describe the specified peer node-to-OLS data link, as well as the associated DWDM span between the two OLSes.

在本文档中,定义了几个附加数据链路子对象,以描述附加链路特性。链路特性通常是CSPF为特定LSP选择路径所需的特性。这些链路特征描述了指定的对等节点到OLS的数据链路,以及两个OLSE之间的相关DWDM跨度。

The format of the Data Link sub-objects follows the format described in [RFC4204] and is shown below for readability:

数据链路子对象的格式遵循[RFC4204]中所述的格式,为便于阅读,如下所示:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
   |    Type       |    Length     |     (Sub-object contents)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
        
    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
   |    Type       |    Length     |     (Sub-object contents)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
        

Type: 8 bits

类型:8位

The Type indicates the type of contents of the sub-object.

类型指示子对象的内容类型。

Length: 8 bits

长度:8位

The Length field contains the total length of the sub-object in bytes, including the Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4.

长度字段包含子对象的总长度(字节),包括类型和长度字段。长度必须至少为4,并且必须是4的倍数。

The following link characteristics are exchanged on a per data link basis.

以下链路特性以每个数据链路为基础进行交换。

2.3.1. Link Group ID
2.3.1. 链接组ID

The main purpose of the Link Group ID is to reduce control traffic during failures that affect many data links. A local ID may be assigned to a group of data links. This ID can be used to reduce the control traffic in the event of a failure by enabling a single ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see Section 2.4.1) to be used for a group of data links instead of individual ChannelStatus messages for each data link. A data link may be a member of multiple groups. This is achieved by including multiple Link Group ID sub-objects in the LinkSummary message.

链路组ID的主要用途是在影响许多数据链路的故障期间减少控制流量。可以将本地ID分配给一组数据链路。该ID可用于在发生故障时减少控制通信量,方法是启用带有链路组信道_状态对象(参见第2.4.1节)的单个信道状态消息用于一组数据链路,而不是每个数据链路的单个信道状态消息。数据链路可以是多个组的成员。这是通过在LinkSummary消息中包含多个链接组ID子对象来实现的。

The Link Group ID feature allows Link Groups to be assigned based on the types of fault correlation and aggregation supported by a given OLS. From a practical perspective, the Link Group ID is used to map (or group) data links into "failable entities" known primarily to the OLS. If one of those failable entities fails, all associated data links are failed and the peer node is notified with a single message.

链路组ID功能允许根据给定OLS支持的故障关联和聚合类型分配链路组。从实际角度来看,链路组ID用于将数据链路映射(或分组)到主要由OLS知道的“故障实体”。如果这些可故障实体中的一个发生故障,则所有关联的数据链路都会发生故障,并向对等节点发送一条消息。

For example, an OLS could create a Link Group for each laser in the OLS. The data links associated with each laser would then each be assigned the Link Group ID for that laser. If a laser fails, the OLS would then report a single failure affecting all of the data links with a Link Group ID of the failed laser. The peer node that receives the single failure notification then knows which data links are affected. Similarly, an OLS could create a Link Group ID for a

例如,OLS可以为OLS中的每个激光器创建链接组。然后,与每个激光器相关的数据链路将被分配该激光器的链路组ID。如果激光器发生故障,OLS将报告一个影响所有数据链路的单一故障,且链路组ID为故障激光器。然后,接收单一故障通知的对等节点知道哪些数据链路受到影响。类似地,OLS可以为用户创建链接组ID

fiber, to report a failure affecting all of the data links associated with that fiber if a loss-of-signal (LOS) is detected for that fiber.

光纤,如果检测到该光纤的信号丢失(LOS),则报告影响与该光纤相关的所有数据链路的故障。

The format of the Link Group ID sub-object (Type = 3, Length = 8) is as follows:

链接组ID子对象(类型=3,长度=8)的格式如下:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Link Group ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Link Group ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The Reserved field should be sent as zero and ignored on receipt.

保留字段应作为零发送,并在收到时忽略。

Link Group ID: 32 bits

链路组ID:32位

Link Group ID 0xFFFFFFFF is reserved and indicates all data links in a TE link. All data links are members of Link Group 0xFFFFFFFF by default.

链路组ID 0xFFFFFF是保留的,表示TE链路中的所有数据链路。默认情况下,所有数据链路都是链路组0xFFFFFF的成员。

2.3.2. Shared Risk Link Group (SRLG) Identifier
2.3.2. 共享风险链接组(SRLG)标识符

This identifies the SRLGs of which the data link is a member. This information may be configured on an OLS by the user and used for diverse path computation (see [RFC4202]).

这标识了数据链路所属的SRLGs。该信息可由用户在OLS上配置,并用于不同路径计算(参见[RFC4202])。

   The format of the SRLG sub-object (Type = 4, Length = (N+1)*4 where N
   is the number of SRLG values) is as follows:
        
   The format of the SRLG sub-object (Type = 4, Length = (N+1)*4 where N
   is the number of SRLG values) is as follows:
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |            (Reserved)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRLG value #1                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRLG value #2                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                             ...                              //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SRLG value #(N-1)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRLG value #N                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |            (Reserved)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRLG value #1                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRLG value #2                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                             ...                              //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SRLG value #(N-1)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRLG value #N                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The Reserved field should be sent as zero and ignored on receipt.

保留字段应作为零发送,并在收到时忽略。

Shared Risk Link Group Value: 32 bits

共享风险链接组值:32位

See [RFC4202]. List as many SRLGs as apply.

参见[RFC4202]。列出尽可能多的SRLGs。

2.3.3. Bit Error Rate (BER) Estimate
2.3.3. 误码率(BER)估计

This object provides an estimate of the BER for the data link.

该对象提供数据链路的误码率估计值。

The Bit Error Rate (BER) is the proportion of bits that have errors relative to the total number of bits received in a transmission, usually expressed as ten to a negative power. For example, a transmission might have a BER of "10 to the minus 13", meaning that, out of every 10,000,000,000,000 bits transmitted, one bit may be in error. The BER is an indication of overall signal quality.

误码率(BER)是相对于传输中接收到的比特总数,具有错误的比特的比例,通常表示为10到负幂。例如,一次传输的误码率可能为“10到负13”,这意味着每传输100000000000位,就有一位可能出错。误码率是总体信号质量的指标。

The format of the BER Estimate sub-object (Type = 5; Length = 4) is as follows:

BER估算子对象(类型=5;长度=4)的格式如下:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |      BER      |   (Reserved)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |      BER      |   (Reserved)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The Reserved field should be sent as zero and ignored on receipt.

保留字段应作为零发送,并在收到时忽略。

BER: 8 bits

误码率:8位

The exponent from the BER representation described above. That is, if the BER is 10 to the minus X, the BER field is set to X.

上述BER表示的指数。也就是说,如果BER为10减去X,则BER字段设置为X。

2.3.4. Optical Protection
2.3.4. 光学保护

This indicates whether the link is protected by the OLS. This information can be used as a measure of link capability. It may be advertised by routing and used by signaling as a selection criterion, as described in [RFC3471].

这表示链路是否受OLS保护。此信息可用作链路能力的度量。如[RFC3471]所述,它可以通过路由进行广告,并通过信令作为选择标准。

The format of the Optical Protection sub-object (Type = 6; Length = 4) is as follows:

光学保护子对象(类型=6;长度=4)的格式如下:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |     (Reserved)    | Link Flags|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |     (Reserved)    | Link Flags|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The Reserved field should be sent as zero and ignored on receipt.

保留字段应作为零发送,并在收到时忽略。

Link Flags: 6 bits

链接标志:6位

Encoding for Link Flags is defined in Section 7 of [RFC3471].

[RFC3471]第7节定义了链路标志的编码。

2.3.5. Total Span Length
2.3.5. 总跨距

This indicates the total distance of fiber in the OLS. This may be used as a routing metric or to estimate delay.

这表示OLS中光纤的总距离。这可以用作路由度量或估计延迟。

The format of the Total Span Length sub-object (Type = 7, Length = 8) is as follows:

总跨距长度子对象(类型=7,长度=8)的格式如下:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Span Length                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Span Length                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The Reserved field should be sent as zero and ignored on receipt.

保留字段应作为零发送,并在收到时忽略。

Span Length: 32 bits

跨距长度:32位

This value represents the total length of the WDM span in meters, expressed as an unsigned (long) integer.

此值表示WDM跨度的总长度(以米为单位),表示为无符号(长)整数。

2.3.6. Administrative Group (Color)
2.3.6. 管理组(颜色)

The administrative group (or Color) to which the data link belongs.

数据链接所属的管理组(或颜色)。

The format of the Administrative Group sub-object (Type = 8, Length = 8) is as follows:

管理组子对象(类型=8,长度=8)的格式如下:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Administrative Group                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |    Length     |           (Reserved)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Administrative Group                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The Reserved field should be sent as zero and ignored on receipt.

保留字段应作为零发送,并在收到时忽略。

Administrative Group: 32 bits

管理组:32位

A 32-bit value, as defined in [RFC3630].

[RFC3630]中定义的32位值。

2.4. Fault Management
2.4. 故障管理

The Fault Management procedure used between a peer and an OLS follows the procedures described in [RFC4204]; some further extensions are defined in this section. The information learned from the OLS-peer fault management procedures may be used to trigger peer-peer LMP fault management, or may be used to trigger GMPLS signaling/routing procedures directly.

对等方和OLS之间使用的故障管理程序遵循[RFC4204]中描述的程序;本节定义了一些进一步的扩展。从OLS对等故障管理程序中获取的信息可用于触发对等LMP故障管理,或可用于直接触发GMPLS信令/路由程序。

Fault management consists of three major functions:

故障管理包括三个主要功能:

1. Fault Detection 2. Fault Localization 3. Fault Notification

1. 故障检测2。故障定位3。故障通知

The fault detection mechanisms are the responsibility of the individual nodes and are not specified as part of this protocol.

故障检测机制由各个节点负责,不作为本协议的一部分指定。

Fault detection mechanisms may include a Bit Error Rate (BER) exceeding a threshold, and loss-of-signal (LOS) and SONET/SDH-level errors. It is the responsibility of the OLS to translate these failures into (Signal) OK, Signal Failure (SF), or Signal Degrade (SD), as described in [RFC4204].

故障检测机制可能包括超过阈值的误码率(BER)、信号丢失(LOS)和SONET/SDH级错误。OLS负责将这些故障转换为(信号)正常、信号故障(SF)或信号降级(SD),如[RFC4204]所述。

That is, an OLS uses the messages defined in the LMP fault localization procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse messages) to inform the adjacent peer node of failures it has detected, in order to initiate the LMP fault localization procedures between peer nodes, but it does not participate in those procedures.

也就是说,OLS使用LMP故障定位程序中定义的消息(ChannelStatus、ChannelStatusAck、ChannelStatusRequest和ChannelStatusResponse消息)将其检测到的故障通知相邻对等节点,以便在对等节点之间启动LMP故障定位程序,但它不参与这些程序。

The OLS may also execute its own fault localization process to allow it to determine the location of the fault along the DWDM span. For example, the OLS may be able to pinpoint the fault to a particular amplifier in a span of thousands of kilometers in length.

OLS还可以执行自己的故障定位过程,以确定DWDM跨度沿线的故障位置。例如,OLS可能能够在数千公里的范围内精确定位特定放大器的故障。

To report data link failures and recovery conditions, LMP-WDM uses the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse messages defined in [RFC4204].

为了报告数据链路故障和恢复情况,LMP-WDM使用[RFC4204]中定义的ChannelStatus、ChannelStatusAck、ChannelStatusRequest和ChannelStatusResponse消息。

Each data link is identified by an Interface_ID. In addition, a Link Group ID may be assigned to a group of data links (see Section 2.3.1). The Link Group ID may be used to reduce the control traffic by providing channel status information for a group of data links. A new LINK GROUP CHANNEL_STATUS object is defined below for this purpose. This object may be used in place of the CHANNEL_STATUS objects described in [RFC4204] in the ChannelStatus message.

每个数据链路由接口标识标识。此外,链路组标识可分配给一组数据链路(见第2.3.1节)。链路组ID可用于通过提供一组数据链路的信道状态信息来减少控制通信量。为此,下面定义了一个新的链路组通道_状态对象。此对象可用于代替ChannelStatus消息中[RFC4204]中所述的CHANNEL_STATUS对象。

2.4.1. LINK_GROUP CHANNEL_STATUS Object
2.4.1. 链接组通道状态对象

The LINK_GROUP CHANNEL_STATUS object is used to indicate the status of the data links belonging to a particular Link Group. The correlation of data links to Group ID is made with the Link Group ID sub-object of the DATA_LINK object.

链路组信道状态对象用于指示属于特定链路组的数据链路的状态。数据链接与组ID的关联是通过数据链接对象的链接组ID子对象实现的。

The format of the LINK_GROUP CHANNEL_STATUS object is as follows (Class = 13, C-Type = 4):

链路组信道状态对象的格式如下(Class=13,C-Type=4):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Group ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                    Channel Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Link Group ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                    Channel Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Group ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                    Channel Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              :                                |
   //                             :                               //
   |                              :                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Link Group ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|                    Channel Status                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Link Group ID: 32 bits

链路组ID:32位

The Link Group ID 0xFFFFFFFF is reserved and indicates all data links in a TE link. All data links are members of the Link Group 0xFFFFFFFF by default.

链路组ID 0xFFFFFF是保留的,表示TE链路中的所有数据链路。默认情况下,所有数据链路都是链路组0xFFFFFF的成员。

Channel Status: 32 bits

通道状态:32位

The values for the Channel Status field are defined in [RFC4204].

信道状态字段的值在[RFC4204]中定义。

This object is non-negotiable.

这个目标是不可谈判的。

3. Security Considerations
3. 安全考虑

LMP message security uses IPsec, as described in [RFC4204]. This document only defines new LMP objects that are carried in existing LMP messages. As such, this document introduces no other new security considerations not covered in [RFC4204].

LMP消息安全性使用IPsec,如[RFC4204]所述。本文档仅定义现有LMP消息中携带的新LMP对象。因此,本文件未引入[RFC4204]中未涉及的其他新安全注意事项。

4. IANA Considerations
4. IANA考虑

LMP [RFC4204] defines the following name spaces and the ways in which IANA can make assignments to these namespaces:

LMP[RFC4204]定义了以下名称空间以及IANA分配给这些名称空间的方式:

- LMP Message Type - LMP Object Class - LMP Object Class type (C-Type) unique within the Object Class - LMP Sub-object Class type (Type) unique within the Object Class

- LMP消息类型-LMP对象类-对象类中唯一的LMP对象类类型(C-Type)-对象类中唯一的LMP子对象类类型(Type)

This memo introduces the following new assignments:

本备忘录介绍了以下新任务:

LMP Object Class Types:

LMP对象类类型:

o under CONFIG class name (as defined in [RFC4204]) - LMP-WDM_CONFIG (C-Type = 2)

o 在配置类名下(如[RFC4204]中所定义)-LMP-WDM_配置(C-Type=2)

o under CHANNEL_STATUS class name (as defined in [RFC4204]) - LINK_GROUP (C-Type = 4)

o 在信道_状态类名(如[RFC4204]中定义)下-链路_组(C-Type=4)

LMP Sub-Object Class names:

LMP子对象类名称:

o under DATA_LINK Class name (as defined in [RFC4204]) - Link_GroupId (sub-object Type = 3) - SRLG (sub-object Type = 4) - BER_Estimate (sub-object Type = 5) - Optical_Protection (sub-object Type = 6) - Total_Span_Length (sub-object Type = 7) - Administrative_Group (sub-object Type = 8)

o 在数据链路类别名称(如[RFC4204]中所定义)下-链路链路组ID(子对象类型=3)-SRLG(子对象类型=4)-BER(子对象类型=5)-光保护(子对象类型=6)-总跨度长度(子对象类型=7)-管理组(子对象类型=8)

5. Contributors
5. 贡献者

The authors would like to acknowledge Osama S. Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John Drake, David Drysdale, W. L. Edwards, Adrian Farrel, Andre Fredette, Rohit Goyal, Hirokazu Ishimatsu, Monika Jaeger, Ram Krishnan, Jonathan P. Lang, Raghu Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan Shantigram, Ed Snyder, George Swallow, Gopala Tumuluri, Yong Xue, Lucy Yong, and John Yu.

作者要感谢Osama S.Aboul Magd、Stuart Brorson、Sudheer Dharanikota、John Drake、David Drysdale、W.L.Edwards、Adrian Farrel、Andre Fredette、Rohit Goyal、Hirokazu Ishimatsu、Monika Jaeger、Ram Krishnan、Jonathan P.Lang、Raghu Mannam、Eric Mannie、Dimitri Papadimitriou、Jagan Shantigram、Ed Snyder、George Swallow、,戈帕拉·图穆鲁里、勇雪、露西·勇和约翰·余。

6. References
6. 工具书类
6.1. Normative References
6.1. 规范性引用文件

[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, September 2005.

[RFC4202]Kompella,K.,Ed.,和Y.Rekhter,Ed.,“支持通用多协议标签交换(GMPLS)的路由扩展”,RFC 4202,2005年9月。

[RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC 4204, September 2005.

[RFC4204]Lang,J.,Ed.“链路管理协议(LMP)”,RFC4204,2005年9月。

[RFC4207] Lang, J., and D. Papadimitriou, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, September 2005.

[RFC4207]Lang,J.和D.Papadimitriou,“链路管理协议(LMP)测试消息的同步光网络(SONET)/同步数字体系(SDH)编码”,RFC 4207,2005年9月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[RFC3471]Berger,L.“通用多协议标签交换(GMPLS)信令功能描述”,RFC 3471,2003年1月。

[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

[RFC3630]Katz,D.,Kompella,K.,和D.Yeung,“OSPF版本2的交通工程(TE)扩展”,RFC 3630,2003年9月。

6.2. Informative References
6.2. 资料性引用

[OLI] Fredette, A., Editor, "Optical Link Interface Requirements", Work in Progress.

[OLI]Fredette,A.,编辑,“光链路接口要求”,正在进行中。

Editors' Addresses

编辑地址

Andre Fredette Hatteras Networks P.O. Box 110025 Research Triangle Park NC 27709-0025, USA

Andre Fredette Hatteras Networks邮政信箱110025美国北卡罗来纳州三角研究园27709-0025

   EMail: Afredette@HatterasNetworks.com
        
   EMail: Afredette@HatterasNetworks.com
        

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

Jonathan P.Lang Sonos,Inc.加利福尼亚州圣巴巴拉市东格拉街223号,邮编93101

   EMail: jplang@ieee.org
        
   EMail: jplang@ieee.org
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2005).

版权所有(C)互联网协会(2005年)。

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

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

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

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

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

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

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

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。