Network Working Group                                        H. Khosravi
Request for Comments: 3604                                         Intel
Category: Informational                                      G. Kullgren
                                                                 S. Shew
                                                         Nortel Networks
                                                               J. Sadler
                                                             A. Watanabe
                                                            October 2003
Network Working Group                                        H. Khosravi
Request for Comments: 3604                                         Intel
Category: Informational                                      G. Kullgren
                                                                 S. Shew
                                                         Nortel Networks
                                                               J. Sadler
                                                             A. Watanabe
                                                            October 2003

Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3)


Status of this Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2003). All Rights Reserved.




This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.


Conventions used in this document


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

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。

1. Overview
1. 概述

This document details the changes to GSMP necessary for the support of optical (non-transparent and all optical), SONET/SDH, and spatial switching of IP packets, Layer 2 (L2) frames and TDM data. When implemented, GSMP controllers will then be able to control: photonic cross-connects (optical-optical), transparent optical cross connects (optical-electrical-optical, frame independent), opaque cross connects (optical-electrical-optical, SONET/SDH frames), and


traditional TDM switches (all electrical). The resulting systems could form IP based optical routers, optical label switches, wavelength routers, and dynamic optical cross connects.


Several different generic models exist defining how to provide control plane functionality in an optical network [2], [3], [4]. This document takes no position on which model is most appropriate (e.g., single or multiple routing plane instances). The only assumption is that the ability to separate the control mechanisms from the data switching is as useful for the signaling of optical paths (e.g., GMPLS) as it is for the signaling of L2 paths (e.g., MPLS). Therefore, the requirements contained within are focused only on the separation of control functions from data functions in order to provide a more flexible network architecture.


GSMPv3 [5] is well suited for providing the control interface necessary for allowing an IP based controller to direct the activities of an optical switch. In order for GSMP to operate between controllers and optical switches and cross connects, support for optical labels and service and resource abstractions must be added to GSMP.


This document also includes changes recommended by implementers that will facilitate easier development of a GSMP implementation. These changes consist of rearranging PDU formats, clarification of flags, transaction identifiers, and response codes.


2. Requirements for Optical Support
2. 光学支架的要求
2.1. Label
2.1. 标签
2.1.1. Label Types
2.1.1. 标签类型

New labels are needed to identify the entities that are to be switched in the optical fabric. These are longer than the labels defined in GSMPv3 as they have physical and structural context. As GMPLS [2], [3] has had very similar requirements for label formats, alignment with GMPLS is proposed. This includes support for:


- Digital Carrier Hierarchy (e.g., DS-1, E1) - SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12) - Plesiochronous Data Hierarchy (PDH) labels [6] - OTN G.709 labels - Lambdas - Fibers

- 数字载波层次结构(如DS-1、E1)-SONET和SDH层次结构(如OC-3、STM-1、VT1.5、VC-12)-准同步数据层次结构(PDH)标签[6]-OTN g.709标签-Lambdas-光纤

GSMP MUST include support for all label types list above, as well as for label hierarchies and label lists as defined by GMPLS. Therefore, the ability to perform operations on groups of the above labels MUST also be supported (e.g., 5 OC-3s, contiguous wavebands).

GSMP必须支持上述所有标签类型列表,以及GMPLS定义的标签层次结构和标签列表。因此,还必须支持对上述标签组执行操作的能力(例如,5 OC-3,连续波段)。

2.1.2. Label Management Issues
2.1.2. 标签管理问题

An updated label range message MUST be provided. There MUST also be support of multiplexing (e.g., no multiplexing, SONET, Gigabit Ethernet multiplexing etc).


2.2. Statistics messages
2.2. 统计信息

Optical switches have a number of different statistics which are not in common with ATM, or Frame Relay switches. Consequently, the statistics messages SHOULD be updated to report Performance Monitoring statistics defined for all new optical transport technologies added to GSMP.


2.3. Configuration Issues
2.3. 配置问题
2.3.1. Switch Configuration
2.3.1. 交换机配置 Layer Switching Identification 层交换识别

Since an Optical Switch may be able to provide connection services at multiple transport layers (i.e., STS-3c, STS-1, VT-1.5, DS3, DS1), and not all switches are expected to support the same transport layers, the switch will need to notify the controller of the specific layers it can support.


Therefore, the Switch Configuration message MUST be extended to provide a list of the transport layers for which an optical switch can perform switching.


2.3.2. Port Configuration
2.3.2. 端口配置

The port configuration message supplies the controller with the configuration information related to a single port. Consequently, extensive additions will need to be made to this command.

端口配置消息向控制器提供与单个端口相关的配置信息。因此,需要对该命令进行大量添加。 Port Type extensions 端口类型扩展

Port types MUST be added to support the mix of optical signals that can operate over a single fiber.


The port information that MAY need to be conveyed includes [7]:


- wavelengths available per interface - bit rate per wavelength - type of fiber

- 每个接口可用的波长-每个波长的比特率-光纤类型 Supported Signal Type extensions 支持的信号类型扩展

Since a port on an optical switch may support signals at multiple transport layers, it is necessary to understand the signals supported, as well as the possible ways that one signal can be transported within another.


For OTN, SONET/SDH and PDH optical switches, the Port configuration message MUST be extended to detail the different transport layer signals that are supported by a port. Furthermore, this extension MUST detail which signals may be transported by another signal.


This mechanism MUST also provide information about optional capabilities (such as virtual concatenation and arbitrary concatenation for SONET/SDH) available on a port.

该机制还必须提供关于端口上可用的可选功能(例如SONET/SDH的虚拟连接和任意连接)的信息。 Trace Mechanism support Identification 跟踪机制支持识别

A number of transport layer signals include overhead channels that can be used to identify the source of a signal. Since they are embedded in the signal, only the network element has access to the signals. However, not all network elements have the capability to set or read the messages in these channels on every port. Consequently, this port attribute needs to be reported to the controller.


The Port Configuration message MUST be extended to report which trace mechanisms are supported by a port.

端口配置消息必须扩展以报告端口支持哪些跟踪机制。 Port Location Identification 港口位置识别

Since contemporary Optical switches have the ability to support tens of thousands of ports in hundreds of shelves located in as potentially as many bays, the current "Slot/Port" location identifier is inadequate.


The Slot/Port Location Identifier MUST be extended to encode Bay/Shelf/Slot/Port.

插槽/端口位置标识符必须扩展为对托架/托架/插槽/端口进行编码。 Port-related Partitioning Extensions 与端口相关的分区扩展

Partitioning can be done for any resource that exists in the network element. The GSMP partitioning draft currently defines ports and switching resources as partitionable resources. Since optical switches may support multiple transport network layers, an additional resource type is introduced: the transport layer signal.


The point where a transport layer signal is inserted into a lower layer signal (called an "access point" by the ITU [8]), is very similar to a port. Therefore, when partitioning is done on a transport layer signal basis, the partition that is the user of the access point MUST have a port that associated with the access point. Labels will then be used in the to describe the subordinate signals.


2.3.3. Service Configuration
2.3.3. 服务配置

While new capability sets MUST be added to support quality parameters in optical switches, no changes are foreseen to the service configuration message as its role to carry the service information as defined in the applicable service model.


2.4. Service Model Issues
2.4. 服务模型问题

While one assumption of using optical media is that bandwidth is plentiful, it should be expected that traffic engineering will be necessary in any case [5]. GSMP provides the means for each connection to be created with specific attributes. Therefore, service parameters will need to be defined for each of the Different Optical technologies.


2.4.1. Transparent Optical
2.4.1. 透明光学

Capability to control re-timing and re-shaping on a per port level MUST be added.


2.4.2. SONET/SDH and OTN

The capability to control the adaptation parameters used when a transport signal is inserted into another transport signal MUST be added. These parameters SHOULD be modifiable at times other than adding a branch so that functions such as Tandem Connection Monitoring can be configured. Currently, the default set of service models in GSMP are all based on the services models defined elsewhere, e.g., the Intserv model [9], [10], the Diffserv [11]


model, ATM QoS models and the Frame relay forum QoS models. A determination needs to be made of the applicable service models for optical channel trails. These models MUST then be mapped to the GSMP capability set mechanism.


2.5. Encapsulation issues
2.5. 封装问题

The working group needs to decide whether a new encapsulation is required. In other words, will all optical switches used in either the MPLS over Optics and the IP over optics applications require that IP be implemented on the control channel connecting the GSMP controller and Optical switch (the GSMP target).

工作组需要决定是否需要新的封装。换句话说,MPLS over Optics和IP over Optics应用中使用的所有光交换机是否要求在连接GSMP控制器和光交换机(GSMP目标)的控制通道上实现IP。

A new encapsulation SHOULD be defined allowing the use of a non-IP raw wavelength control connection.


Likewise, a new encapsulation SHOULD be defined allowing GSMP to be used in legacy Data Communication Network (DCN) environments that use OSI CLNP.

同样,应该定义一个新的封装,允许GSMP在使用OSI CLNP的传统数据通信网络(DCN)环境中使用。

The security risks of additional non-IP encapsulations MUST be described, since the mandatory to implement mechanism of IPsec is not available for these control channels, as in the RFC 3293 Ethernet and ATM cases. It is in scope to perform risk analysis and describe if mechanisms for link-level security mitigate the risk.

必须说明附加非IP封装的安全风险,因为强制实施IPsec机制不适用于这些控制通道,如RFC 3293以太网和ATM情况。执行风险分析和描述链路级安全机制是否降低风险属于范围。

2.6. MIB Issues
2.6. MIB问题

If a new encapsulation is defined, then the encapsulation group SHOULD be updated. No other changes should be required.


2.7. OXC Transaction Model
2.7. OXC事务模型
2.7.1. Serial Transactions
2.7.1. 连续交易

Many existing OXCs use a command interface which assumes a serial transaction model. That is, a new command cannot be issued or processed until the existing command is completed. Under provisioning control via a network management application, and with non-dynamic path setup, this model has been adequate.


Moving to a dynamic path setup capability with a distributed control plane, a parallel transaction model is likely required for performance. This is particularly helpful when the performance of setting up a TDM style connection is much slower than setting up an L2 connection table. If the OXC is not able to support a parallel transaction model, a GSMP controller MUST be informed of this and adopt serial transaction behavior.


2.7.2. Bulk Transactions
2.7.2. 批量交易

Again due to the time it may take some OXCs to setup TDM connections relative to L2 fabrics (e.g., VC-4/STS-1 SPE fabric in an HOVC/STS switch), support for sending multiple transactions in the same message is a useful optimization. When an OXC receives a bulk message, the individual transactions are acted upon and a single reply is sent. If parallel transactions are not supported, bulk messages can improve performance by reducing transaction overhead. Bulk transactions SHOULD be supported.

同样,由于一些OXC可能需要花费一些时间来设置与L2结构(例如,HOVC/STS交换机中的VC-4/STS-1 SPE结构)相关的TDM连接,因此支持在同一消息中发送多个事务是一个有用的优化。当OXC接收到批量消息时,将对单个事务执行操作,并发送单个回复。如果不支持并行事务,则批量消息可以通过减少事务开销来提高性能。应支持批量事务。

2.8. OXC Protection Capabilities
2.8. OXC保护能力

To achieve good link protection performance (e.g., 50 ms after failure detection), SONET/SDH and some OXC systems use hardware based protection schemes (e.g., ring protection). Achieving this level of performance solely using a data control plane such as GMPLS is a serious challenge. An alternate approach is to utilize protection capabilities of an OXC with a dynamic control plane. An implication of this hybrid approach is that extensions are needed to GSMP to provision the behavior of an OXC in anticipation of a link failure.


This differs from the strict master-slave relationship in GSMP for Layer 2 switches in that here the OXC is capable of taking an action independent of the GSMP controller and then informing the controller afterwards. Consequently, the GSMP port configuration command MUST be extended to allow autonomous protection behaviors to be provisioned into the Network Element.

这与第2层交换机的GSMP中严格的主从关系不同,在这里,OXC能够独立于GSMP控制器采取行动,然后通知控制器。因此,必须扩展GSMP port configuration命令,以允许在网元中提供自主保护行为。

Furthermore, the controller MUST be able to provide the parameters for when reversion from a backup link to the original link is allowed. This may take the form of hold-off timers, BER parameters, or the requirement for controller directed reversion.


2.8.1. Non-Reserved Protection Links
2.8.1. 非保留保护链路

An example of protection OXC behavior is that when a link fails, a backup link may be used to protect traffic on. This backup link could be selected from a set of links, none of which are pre-reserved. A backup link could be shared with one or more "working" links which is a form of 1:n shared protection. Specifying the set of possible backup links SHOULD be done as an option to the Add-Branch message.


When a backup link is used or the OXC reverts back to the original link, the control plane (i.e., signaling) may need to know about the new path state in order to notify the operator, or take some other OAM action (e.g., billing, SLA monitoring). An additional GSMP message to inform the controller SHOULD be added to do this.


2.8.2. Dedicated Protection Links
2.8.2. 专用保护链路

A more specialized form of restoration called "1+1" defines a (usually node disjoint) protection path in a transport/optical network for a given working path. At the ingress node to the path, the traffic signal is sent simultaneously along both working and protection paths. Under non-failure conditions at the egress node, only the last link of the working path is connected to the client. When any link in the working path fails, traffic on the working path ceases to be received at end of the path. The egress OXC detects this condition and then switches to use the last link of the protection path without the controller having to issue a Move-Input-Branch message. At no time is the ingress node aware which link the egress node is using. Selection of the protection path and all of its links is outside the scope of GSMP.


Specification of the two output branches at the ingress node can be done with the usual Add-Branch semantics. The ingress node protection link is not shared with any other working link.


Specification of the two input branches at the egress node should be done when the Add-Branch message is sent. This SHOULD be an option to that message. The egress node protection link is not shared with any other working link.

在发送Add Branch消息时,应该指定出口节点上的两个输入分支。这应该是该消息的一个选项。出口节点保护链路不与任何其他工作链路共享。

When a protection link is used or the OXC reverts back to the working link, the control plane (i.e., signaling) may need to know about the new path state in order to notify the operator, or take some other OAM action (e.g., billing, SLA monitoring). An additional GSMP message to inform the controller SHOULD be added to do this.


If an alternate input port is not specified with an original Add-Branch message, it MAY be specified in a subsequent Add-Branch message. In this case, it is useful to include information about existing users of the output port in that Add-Branch message. This helps the OXC immediately learn of the association between the new input port and an existing one. The association is used to enable OXC protection procedures. This capability MUST be added to the add-branch message.


Similar contextual information is needed for a Delete-Branch message so that the OXC can determine if a path becomes unprotected. This capability MUST be added to the Delete-branch message.


2.8.3. Protection Triggers
2.8.3. 保护触发器

Aside from link or equipment failures, there are a variety of maintenance conditions that could cause the backup/protection link(s) to be used. These may include:


- Scheduled maintenance of the working link. Here the network operator deliberately takes a link out of service to perform maintenance. - Reconfiguration of fiber/node/network which causes temporary need to use backup links.

- 工作链路的计划维护。在这里,网络运营商故意中断一条链路以进行维护。-重新配置光纤/节点/网络,导致临时需要使用备份链路。

It may be useful to specify these triggers when the backup/protection links are defined with the Add-Branch message. This depends on how the OXC is implemented to be aware of such triggers. This is for further study.


2.8.4. Protection Link Capabilities
2.8.4. 保护链路能力

When an OXC has the capability to perform protection switching independently from the Optical Call Controller (OCC), it may be useful for the OCC to be informed of these capabilities at switch and/or port configuration. Applications in the GSMP controller could use this information. For example, signaling clients could define a path protection scheme over multiple GSMP enabled OXCs. This is for further study.


2.9. Controller directed restoration
2.9. 控制器定向恢复

Bi-directional Connection Replacement


Connections in the transport network are inherently point-to-point bi-directional. Unfortunately, GSMPv3 currently does not allow for the B and R flags to be set on an add branch message. This means that it is not possible to do an atomic replacement of a bi-directional connection -- an action that is desirable for controller directed restoration. Consequently, the protocol MUST be changed to allow these flags to be used at the same time.


2.10. Support for optical burst switching
2.10. 支持光突发交换

GSMP for Optical Switching should also support optical burst switching. As described in [12], [13], and [14], part of burst switching connection setup includes reserving time on the transport medium for the client.


This time is characterized by two parameters: a start time and the duration. These values MAY define a one-time reservation or a repeating reservation. Upon a request for setup of a burst connection, the GSMP controller MUST perform appropriate Connection Admission Control for the time and duration specified and, if the connection is allowed, MUST signal these parameters to the burst switching device to reserve the exact bandwidth required [12], [14]. The burst switch MUST perform the switching operation autonomously, using the synchronization methods prescribed for the burst network it is operating in.


3. Requirements from Implementers
3. 实施者的需求

This section describes requirements to GSMP v3 based on some implementation experience. They address areas of ambiguity, missing semantics, and configuration recommendations.

本节根据一些实施经验描述对GSMP v3的要求。它们解决了歧义、语义缺失和配置建议方面的问题。

3.1. GSMP Packet Format
3.1. GSMP数据包格式

The Basic GSMP Message Format in chapter 3.1.1 in [5] describes the common fields present in all GSMP messages except for the Adjacency protocol.


3.1.1. Message segmentation
3.1.1. 消息分段

If a message exceeds the MTU of the link layer it has to be segmented. This was originally done with the "More" value in the Result field. The addition of the I flag and the SubMessage Number to the header has made the "More" value obsolete.


The I flag and SubMessage numbers should be used in all messages that can be segmented.

I标志和子消息编号应在所有可分段的消息中使用。 SubMessage Number and I flag 子消息编号和I标志

It should be specified if the SubMessage Number starts on 0 or 1 in a segmented message and what value the I flag should have in an message that is not segmented.

应指定分段消息中的子消息编号是否从0或1开始,以及未分段消息中的I标志应具有的值。 Message Length 消息长度

Clarification of what value should be used in the Length field for segmented messages. Specifically, does the Length field contain the total length of the message or the length of the current segment.

澄清分段消息的长度字段中应使用的值。具体来说,长度字段是否包含消息的总长度或当前段的长度。 Message Segmentation example 消息分段示例

To avoid all ambiguity an example of message segmentation should be provided.


3.1.2. Transaction Identifier
3.1.2. 事务标识符

The Transaction Identifier in [5] does not distinguish between replies from a request with "AckAll" and "NoSuccessAck". It also does not provide any information about how to handle replies where the Transaction ID doesn't match a Transaction ID from a previously sent request.


If multiple controllers are connected to a single switch and the switch sends an event message with "ReturnReceipt" set to all of them, there is no way for the switch to identify which controller the receipt is coming from.


The "ReturnReceipt" value should not be permitted for Events.


3.2. Window Size
3.2. 窗口大小

The Switch Configuration Message defined in chapter 8.1 in [5] defines a Window size to be used by the controller when sending messages to the switch. It is not stated if this window should apply to all messages or only to messages that will always generate a reply.


If messages that may not generate a reply should be counted against the window a time-out period when they are to be removed from the window should be defined.


It is not defined if the window should be cleared when the adjacency is lost and later recovered.


3.3. Retransmission
3.3. 重传

A retransmission policy with a well-designed exponential backoff should be used if no reply is received for a message with "AckAll" set.


3.4. Delete Branches Message
3.4. 删除分支消息

The "Delete Branch Element" has a 4 bit Error field that should be redefined to match the size of the "Failure Response Codes".


3.5. Adjacency
3.5. 邻接

The chapter about how to handle a new adjacency and re-established adjacencies should be clarified.


3.5.1. Loss of Synchronization
3.5.1. 同步丢失

The switch must not reset the connection states if another adjacency has already been established since this would destroy an already valid state.


4. Security Considerations
4. 安全考虑

The security of GSMP's TCP/IP control channel has been addressed in [15]. Any potential remaining security considerations are not addressed in this requirements document.


5. Acknowledgements
5. 致谢

The list of authors provided with this document is a reduction of the original list. Currently listed authors wish to acknowledge that a substantial amount was also contributed to this work by: Avri Doria and Kenneth Sundell


The authors would like to acknowledge the careful review and comments of Dimitri Papadimitriou, Torbjorn Hedqvist, Satoru Okamoto, and Kohei Shiomoto.

作者要感谢Dimitri Papadimitriou、Torbjorn Hedqvist、Satoru Okamoto和Kohei Shiomoto的仔细审查和评论。

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

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

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

6.2. Informative References
6.2. 资料性引用

[2] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.

[2] Berger,L.,Ed.“通用MPLS-信令功能描述”,RFC 3471,2003年1月。

[3] Mannie, E., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Work in Progress, May 2003.

[3] Mannie,E.等人,“通用多协议标签交换(GMPLS)体系结构”,正在进行的工作,2003年5月。

[4] ITU-T Recommendation, "Architecture for the Automatically Switched Optical Network (ASON)", G.8080/Y.1304, January 2003

[4] ITU-T建议,“自动交换光网络(ASON)的体系结构”,G.8080/Y.13042003年1月

[5] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol V3", RFC 3292, June 2002.

[5] Doria,A.,Sundell,K.,Hellstrand,F.和T.Worster,“通用交换机管理协议V3”,RFC 3292,2002年6月。

[6] Sadler, J., Mack-Crane, B., "TDM Labels for GSMP", Work in Progress, February 2001.

[6] Sadler,J.,Mack Crane,B.,“GSMP的TDM标签”,正在进行的工作,2001年2月。

[7] Rajagopalan, B., et al., "IP over Optical Networks: A Framework", Work in Progress, September 2003.

[7] Rajagopalan,B.等人,“光网络IP:框架”,正在进行的工作,2003年9月。

[8] ITU-T Recommendation, "Generic functional architecture of transport networks", G.805, March 2000.

[8] ITU-T建议,“传输网络的通用功能架构”,G.8052000年3月。

[9] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, June 1994.

[9] Braden,R.,Clark,D.和S.Shenker,“互联网体系结构中的综合服务:概述”,RFC16331994年6月。

[10] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.

[10] Wroclawski,J.,“受控负荷网元服务规范”,RFC2211,1997年9月。

[11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, _"An Architecture for Differentiated Services", RFC 2475, December 1998.

[11] Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.和W.Weiss,“差异化服务的架构”,RFC 24751998年12月。

[12] C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical Burst Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, pp.36-44.

[12] 乔,M.Yoo,“光突发交换的选择、特点和问题”,光网络。杂志,第一卷,第二期,2000年4月,第36-44页。

[13] Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan Stevension, "JumpStart: A Just-in-time Signaling Architecture for WDM Burst-Switching Networks", IEEE Comm. Mag., Fab. 2002.

[13] Ilia Baldine,George N.Rouskas,Harry G.Perros,Dan Stevension,“JumpStart:WDM突发交换网络的即时信令架构”,IEEE Comm.Mag.,Fab。2002

[14] Sanjeev Verma, et al. "Optical burst switching: a viable solution for terabit IP backbone", IEEE network, pp. 48-53, Nov/Dec 2000.

[14] Sanjeev Verma,等人,“光突发交换:一种适用于太比特IP主干网的可行解决方案”,IEEE网络,第48-53页,2000年11月/12月。

[15] Worster, T., Doria, A. and J. Buerkle, "GSMP Packet Encapsulations for ATM, Ethernet and TCP", RFC 3293, June 2002.

[15] Worster,T.,Doria,A.和J.Buerkle,“ATM、以太网和TCP的GSMP数据包封装”,RFC 3293,2002年6月。

7. Authors' Addresses
7. 作者地址

Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA


   Phone: +1 503 264 0334
   Phone: +1 503 264 0334

Georg Kullgren Nortel Networks AB S:t Eriksgatan 115 A P.O. Box 6701 SE-113 85 Stockholm Sweden

格奥尔格·库尔格伦北电网络股份有限公司S:t埃里克斯加坦115 A信箱6701 SE-113 85瑞典斯德哥尔摩


Jonathan Sadler Tellabs Operations, Inc. 1415 West Diehl Road Naperville, IL 60563

Jonathan Sadler Tellabs Operations,Inc.伊利诺伊州纳珀维尔西迪尔路1415号,邮编60563

   Phone: +1 630-798-6182
   Phone: +1 630-798-6182

Stephen Shew Nortel Networks PO Box 3511 Station C Ottawa, ON K1Y 4H7

Stephen Shew Nortel Networks邮政信箱3511,渥太华C站,K1Y 4H7


Kohei Shiomoto



Atsushi Watanabe Nippon Telegraph and Telephone Corporation 807A 1-1 Hikari-no-oka, Yokosuka-shi Kanagawa 239-0847, Japan

渡边阿特寿日本电报电话公司807A 1-1 Hikari no oka,横须贺市神奈川239-0847,日本


Satoru Okamoto Nippon Telegraph and Telephone Corporation 9-11 Midori-cho 3-chome, Musashino-shi Tokyo 180-8585, Japan

冈本佐藤日本电报电话公司9-11 Midori cho 3-chome,武藏县,东京180-8585

8. Full Copyright Statement
8. 完整版权声明

Copyright (C) The Internet Society (2003). All Rights Reserved.


This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.






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