Internet Draft Network Working Group D.Papadimitriou Internet Draft M.Fontana Document: draft-papadimitriou-onni-frame-01.txt G.Grammel Expiration Date: May 2001 Alcatel Yanguang Xu Zhi-Wei Lin S.Sankaranarayanan Lucent Raj Jain Nayna Networks Yang Cao Sycamore Yong Xue UUNet November 2000 Optical Network-to-Network Interface Framework and Signaling Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft specifies the optical Network-to-Network Interface (NNI) requirements for non-packet-switch capable transport networks. This proposal defines for such networks the NNI signaling and routing requirements as well as the corresponding mechanisms and procedures. Papadimitriou et al. Expires May 2001 1 draft-papadimitriou-onni-frame-01.txt November 2000 The main objective is to propose a common approach for most of the models currently available for non-packet-switch optical transport networks. The signaling paradigm implicitly referenced within this document is the one defined by the G.MPLS concept. However, in a first approach, this proposal is not focused on a specific and detailed implementation of the G.MPLS signaling protocol. 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 RFC-2119. Table of Contents 1. Introduction..................................................3 2. Terminology...................................................4 3. NNI Reference Model...........................................5 3.1 Client-to-Network Boundary and Network-to-network model...5 3.2 Network-to-network model..................................6 3.2.1 Network-to-network - Model Overview ................6 3.2.2 Network-to-network - Reference Models...............9 4. Signaling transport mechanisms at the NNI.....................10 4.1 NNI Signaling Requirements................................10 4.2 NNI Signaling Transport Mechanisms........................11 4.3 Availability of Signaling Network.........................12 4.4 Security of the Signaling Network.........................12 5. Neighbor discovery protocol...................................13 5.1 Neighbor discovery related concepts.......................13 5.2 Neighbor identity discovery...............................14 5.2.1 Basic identification-related discovery..............14 5.2.2 Additional Identification-related discovery.........14 6. NNI Topology and Resource Distribution Protocol...............15 6.1 Transport Mechanism.......................................16 6.2 Protocol Requirements.....................................16 6.3 TrDP Discovery Protocol...................................17 6.3.1 Logical-port Resource discovery.....................17 6.3.2 Logical-port Address discovery......................18 6.3.3 Logical-port Service discovery......................19 6.4 TrDP Protocol Mechanisms..................................21 6.4.1 ONE Advertisements and Flooding Process.............21 6.4.2 Topology and Local ONE Database.....................22 6.4.3 Flooding rules......................................24 6.4.4 ONE Advertisement types.............................26 6.4.5 Additional mechanisms...............................26 7. NNI Signaling Mechanisms and Protocol.........................27 7.1 UNI G.LSP Signaling Services..............................27 7.2 NNI Signaling Requirements................................27 7.3 NNI Signaling Paradigm and Protocols......................28 7.4 NNI Signaling Interfaces..................................28 7.5 NNI Signaling Messages....................................30 Papadimitriou et al. Expires May 2001 2 draft-papadimitriou-onni-frame-01.txt November 2000 7.5.1 G.LSP Creation......................................30 7.5.2 G.LSP Deletion......................................33 7.5.3 G.LSP Modification..................................35 7.5.4 G.LSP Status........................................38 7.5.5 Notifications.......................................39 7.6 Constraint-based Routing..................................39 7.6.1 Bi-directional G.LSP setup..........................39 7.6.2 Explicit route......................................40 7.6.3 Record route........................................43 7.7 Extended NNI Signaling Services...........................44 7.7.1 Framing-Bandwidth _ Priority........................45 7.7.2 Protection _ Priority...............................46 7.7.3 Preemption..........................................46 8. Hierarchical Network Model....................................47 1. Introduction The framework presented in this proposal combines the Domain Service Model between the client and the optical network whose architecture is based on a centralized or a distributed model. Within this model, the signaling and routing interface between the client and the optical network is referred as the User-to-Network Interface (UNI); and the signaling and routing interface between element belonging to the optical network as the Network-to-Network Interface (NNI). This is the only postulate included within this proposal except that we do not consider in a first approach packet-switch capable devices within the optical network. Many models have been developed for the client network inter- connection: peer, overlay and augmented models are the most familiar; this is also the case concerning the routing model: integrated, overlay and domain specific. Since we consider a boundary interface between the client network and the optical network, combination of the peer model and integrated routing are precluded at the UNI. Since, there is no direct relationship between the model and the signaling, more precisely the signaling paradigm and signaling transport protocol, this proposal covers any kind of optical network model using any kind of signaling paradigm and protocol. The remainder of the document is organized as follows: Section 3 presents the network-to-network models by detailing the specific features of the distributed and centralized models. Section 4 describes the requirements and mechanisms of the NNI signaling transport. The section 5 is dedicated to the Neighbor Discovery Protocol (NDP), which is closely related to the Topology and resource Distribution Protocol (TrDP) explained in section 6. This section includes the TrDP protocol requirements, mechanisms and Papadimitriou et al. Expires May 2001 3 draft-papadimitriou-onni-frame-01.txt November 2000 related discovery processes. The section 7 is entirely dedicated to the NNI signaling. In this section, the NNI signaling requirements, protocols and abstract messages are detailed. Finally, section 8 presents the hierarchical optical network model. 2. Terminology The following terms are used in this document. These definitions take into account the terminology already defined by the IETF for some of the concepts defined here and some are adapted from the OIF Forum terminology. - Optical Network: a collection of optical sub-networks constituted by optical network elements. - Optical Network Element (ONE): a network element belonging to the optical network. An optical network device could be an Optical Cross-Connect (OXC), Optical ADM (OADM), etc. - ONE controller: the owner of the UNI-N interface (since the UNI-N may not belong to the same device as the ONE) toward the UNI-C interface and/or the owner of the NNI interface. - Boundary ONE: an optical network element belonging to the optical network whose controller includes an IrDI-NNI interface and an IaDI- NNI interface and/or an UNI-N interface. - Internal ONE: an optical network element internal to the optical network (also referred as a termination incapable device) whose controller has only IaDI-NNI interface. - Client Network Element (CNE): a network element belonging to the client network. A client network element could be a SONET/SDH ADM, a SONET/SDH Cross-connect, an ATM Switch, an Ethernet switch, an IP router, etc. - CNE controller: the owner of the UNI-C interface (since the UNI-C may not belong to the same device as the boundary CNE) - Optical Network Controller (ONC): logical entity within an optical sub-network terminating the NNI signaling. - Intra-Domain (IaDI)-NNI Interface: the interface between Internal ONE controllers belonging to the same optical sub-network or between Internal ONE controllers belonging to distinct optical sub-networks. - Inter-Domain (IrDI)-NNI Interface: the interface between Boundary ONE controllers belonging to distinct optical networks. - Generalized Label Switched Path (G.LSP): point-to-point connection with specified attributes (mandatory and optional) established between two termination points in the optical network. G.LSPs are Papadimitriou et al. Expires May 2001 4 draft-papadimitriou-onni-frame-01.txt November 2000 considered as bi-directional (and in a first phase as symmetric). A G.LSP could be a Fiber Switched path, Lambda Switched path or TDM Switched path (Circuit). However, within the scope of the first version of this draft, we restrict the network to a non-packet switch capable network and the G.LSPs to non-packet switch capable LSPs. - G.LSP termination-point: an addressable termination-point in the optical network between which a G.LSP is established through the UNI signaling. - UNI Client (UNI-C): signaling and routing interface between a Boundary CNE controller and an ONE controller belonging to an optical network. - UNI Network (UNI-N): signaling and routing interface between a Boundary ONE controller and a CNE controller belonging to a client network. - UNI Services: the services defined at the UNI are the following: - Neighbor discovery service - Service discovery service - G.LSP signaling services (create/delete/modify/status) - NNI Protocols: the protocols defined at the NNI are the following: - Neighbor discovery protocol - Topology and resource Distribution Protocol (OSPF based protocol - Traffic engineering (CSPF based) - G.LSP signaling protocol (CR-LDP based or RSVP-TE protocol) - NMI interface: the interface between the ONE controller and the centralized management server. Concerning the relationship with this terminology and others [ITU-T] we consider within this document that the term Client is equivalent to User, Optical network to Service provider network, Controller to Signaling agent, Trusted to Private and Untrusted to Public. 3. NNI Reference Model This section introduces the NNI reference model by first recalling some basic aspects concerning the UNI reference model. 3.1 Client-to-Network Model The network-to-network model is related to the client-to-network model. For the sake of this proposal, we first briefly describe the client-to-network model. For more details concerning the corresponding reference model refer to [MPLS-OUNI]. Papadimitriou et al. Expires May 2001 5 draft-papadimitriou-onni-frame-01.txt November 2000 +------------+ -----| MGT Server |----- | +------------+ | | | | NMI | NMI +----------------+ +----------------+ +----------------+ |+--------------+| |+--------------+| |+--------------+| || Boundary CNE || || Boundary ONE || || Internal ONE || || Controller || UNI || Controller || IaDI || Controller || || || || || -NNI || || || UNI-C||_._._||UNI-N IaDI-NNI||_._._.||IaDI-NNI || |+--------------+| |+--------------+| |+--------------+| | | | | | | | | | | | | | | | | | | |+--------------+| |+--------------+| |+--------------+| || ||-----|| || || || || Boundary CNE ||-----|| Boundary ONE ||======|| Internal ONE || || ||-----|| || || || |+--------------+| |+--------------+| |+--------------+| +----------------+ +----------------+ +----------------+ Figure 1: Client-to-Network Boundary and Network-to-Network Model UNI signaling communication takes place between UNI-Client (UNI-C) and UNI-Network (UNI-N) as referenced by the OIF document through the UNI signaling channel. Thus the server implements the UNI-N interface and the client the UNI-C interface. Details concerning the signaling transport mechanism are detailed in the OIF Contribution [OIF2000.200]. Details concerning the UNI Reference models are detailed in the OIF Contribution [OIF2000.125.2], User Network Interface v1.0 Proposal and in the IETF Informational Draft [MPLS-OUNI]. 3.2 Network-to-network Model The network-to-network reference models include the centralized and distributed approaches of the optical intra- and inter-networking concept. 3.2.1 Network-to-network: Model Overview The distributed approach of network-to-network model is represented by the following figure: Papadimitriou et al. Expires May 2001 6 draft-papadimitriou-onni-frame-01.txt November 2000 +-------------+ |Internal ONE1| IaDI-NNI |Optical SubN1|------ +-------------+ | +-------------+ IrDI-NNI +-------------+ ------|Boundary ONE3|----------|Boundary ONE8| +-------------+ ------|Optical SubN1|----------|Optical SubN3| |Internal ONE2| | +-------------+ +-------------+ |Optical SubN1|------ | | | | +-------------+ IaDI-NNI | | | | |IrDI-NNI | | |IrDI | | | |-NNI | | | | | | | | +-------------+ IaDI-NNI +-------------+ IrDI-NNI +-------------+ |Internal ONE4|-------------|Boundary ONE5|----------|Boundary ONE9| |Optical SubN2|-------------|Optical SubN2|----------|Optical SubN4| +-------------+ +-------------+ +-------------+ | | | | | | | |IaDI-NNI | |IaDI-NNI | | | | | +-------------+ IaDI-NNI +-------------+ |Internal ONE6|-------------|Internal ONE7| |Optical SubN2|-------------|Optical SubN2| +-------------+ +-------------+ Figure 2: Network-to-network: Distributed Model Overview Within this figure, we have 4 optical sub-networks, 4 boundary ONEs and 5 internal ONEs: - Optical sub-network1 includes 2 internal ONEs and 1 boundary ONE - Optical sub-network2 includes 3 internal ONEs and 1 boundary ONE - Optical sub-network3 includes 1 boundary ONE - Optical sub-network4 includes 1 boundary ONE The same optical network can be represented in the centralized approach for the optical sub-network1 (others are not represented for clarity of the figure): Papadimitriou et al. Expires May 2001 7 draft-papadimitriou-onni-frame-01.txt November 2000 +---------+ ===================| ONC |=== | ========|NNI Agent| | | | +---------+ | | | | | +-------------+ | | |Internal ONE1| | | |Optical SubN1|---- | | +-------------+ | +-------------+IrDI-NNI+-------------+ | -----|Boundary ONE3|--------|Boundary ONE8| | +-------------+ -----|Optical SubN1|--------|Optical SubN3| | |Internal ONE2| | +-------------+ +-------------+ ===|Optical SubN1|-- | | | | +-------------+ | | | | |IrDI-NNI IrDI-NNI| | | | | | | | | | | +-------------+IaDI-NNI+-------------+IrDI-NNI+-------------+ |Internal ONE4|--------|Boundary ONE5|--------|Boundary ONE9| |Optical SubN2|--------|Optical SubN2|--------|Optical SubN4| +-------------+ +-------------+ +-------------+ | | | | | | | |IaDI-NNI | |IaDI-NNI | | | | | +-------------+IaDI-NNI+-------------+ |Internal ONE6|--------|Boundary ONE7| |Optical SubN2|--------|Optical SubN2| +-------------+ +-------------+ Figure 3: Network-to-network: Centralized Model Overview The Optical Network Controller (ONC) includes an NNI agent which implements the inter-domain NNI interface functions and terminates the inter-domain NNI signaling. The ONC may also implement the intra-domain NNI interface functions and terminate the intra-domain NNI signaling. This proposition considers the inter-optical sub-networks communication. In this case, as indicated in the above figures, there is a clear distinction between NNI interfaces: - an IaDI-NNI interface for the intra-domain NNI interface - an IrDI-NNI interface for the inter-domain NNI interface To distinguish between trusted and untrusted peers, we propose a separate definition between a Trusted NNI interface and a Untrusted NNI interface: - Untrusted interface is defined as an NNI interface between two ONEs belonging to distinct administrative authorities (untrusted NNI relationship). Papadimitriou et al. Expires May 2001 8 draft-papadimitriou-onni-frame-01.txt November 2000 - Trusted interface is defined as an NNI interface between two ONEs belonging to the same administrative authority defines a (trusted NNI relationship). So, for instance, in figure 2, ONE1 is connected to ONE3 and they belong to the same administrative authority; hence, the NNI interface between these devices is considered as a trusted NNI interface. In the same figure, the ONE3 is also connected to ONE8 but they do not belong to the same administrative authority; hence the NNI interface between these devices is considered as an untrusted NNI interface. Under the model specified here above, the optical network control plane is based on the following components: - boundary ONE controllers - and internal ONE controllers or the following logical interfaces: - IaDI-NNI interfaces - and IrDI-NNI interfaces It has to be noticed that a boundary ONE Controller can have both IaDI-NNI interface and IrDI-NNI interface. The control interface between the ONE-Controller and the ONE (even if this interface does not concern the NNI specifications) is dedicated to the communication between the ONE and the ONE- Controller. So, this proposal considers to optionally make a distinction between internal and external control interface: - an Internal Control Interface (ICI) refers to an ONE and an ONE-C located in the same element - an External Control Interface (ECI) refers to an ONE and an ONE-C located in separated elements. 3.2.2 Network-to-network - Reference Models Reference models are based on the centralized (1) and distributed models (2) and the following concepts: - within an optical sub-network, NNI interfaces are defined as Trusted IaDI-NNI interfaces - between optical sub-networks, NNI interfaces are defined as either Trusted IaDI-NNI interfaces or Trusted IrDI-NNI interfaces - between optical networks, NNI interfaces are defined as Untrusted IrDI-NNI interfaces 1. Centralized model Within an optical sub-network, all ONE controllers are concentrated on a single instance, the Optical Network Controller meaning there is no IaDI-NNI signaling between ONEs belonging to the same optical sub-network. Papadimitriou et al. Expires May 2001 9 draft-papadimitriou-onni-frame-01.txt November 2000 Between optical sub-networks, Trusted NNI signaling starts at the ONC but can end either at the ONC of the neighboring sub-network or the NNI interface of a neighboring ONE. In the first case, we have a centralized-to-centralized NNI signaling and in the second case a centralized-to-distributed NNI signaling. The same concept applies between optical networks, Untrusted NNI signaling starts at the IrDI-NNI interface of the ONC controller but can end either at the ONC of the neighboring optical network or the Untrusted NNI interface of a neighboring ONE. 2. Distributed model Within an optical sub-network, all ONE controllers are distributed and ONE-to-ONE controller communication is performed through the IaDI-NNI interface of each the ONE controllers. There is at least one IaDI-NNI signaling channel between each ONE controller. Between optical sub-networks, Trusted NNI signaling starts at the NNI interface of the ONE controller and ends either at the ONC of the neighboring sub-network or at the NNI interface of a neighboring ONE. In the first case, we have a distributed-to-centralized NNI signaling and the second a distributed-to-distributed NNI signaling. The same concept applies between optical networks, Untrusted NNI signaling starts at the IrDI-NNI interface of ONE controller but can end either at the ONC of the neighboring optical network or the Untrusted NNI interface of a neighboring ONE. 4. Signaling transport mechanisms at the NNI This section details the NNI signaling requirements and the NNI signaling transport mechanisms; the availability and security of the signaling network are also considered here. Moreover, this section does not make any distinction between the intra- and inter-domain NNI interfaces within the scope of the considered models since the corresponding transport mechanisms do not depend on the NNI interface function. Additionally, and for the same reason, there is no distinction between untrusted and trusted NNI interfaces within this section. Concerning the signaling transport mechanism, the centralized model is a particular case to be considered since the NNI signaling starts at the local ONC and ends at the neighboring ONC controller. 4.1 NNI Signaling Requirements Before specifying the signaling transport mechanism at the NNI, we first describe the signaling requirements for both in-band and out- of-band NNI control-channels: Papadimitriou et al. Expires May 2001 10 draft-papadimitriou-onni-frame-01.txt November 2000 - Between the NNI interfaces, the signaling protocol could be IP- based; the NNI interface IPv4 address is the one uniquely associated to the ONE controller. - Knowledge of the NNI IPv4 address could be static or dynamic, i.e., the NNI discovers the NNI IPv4 address of its neighboring ONEs through the Neighbor Discovery Protocol. - When an ONE is connected through multiple interfaces to a neighboring ONE (i.e., there are multiple transport links between these ONEs), only one NNI control-channel must be logically defined between these ONEs. - Availability of the NNI control-channel mechanism could be based on PPP Multi-link protocol. In a first phase, we do not consider the use of the Link Management Protocol for this functionality as proposed by the [MPLS_LMP]. In case of an out-of-network signaling mechanism, the signaling requirements are the same but apply between ONC controllers: - Between the NNI interfaces, the signaling protocol could be IP- based, the NNI interface IPv4 address is the one uniquely associated to the NNI signaling agent of the ONE/ONC Controller. - Knowledge of the NNI IPv4 address could be static or dynamic, i.e., the NNI discovers the NNI IPv4 address of its neighboring ONE/ ONC Controller NNI signaling agent. The corresponding discovery protocol requires further investigation. - When the ONC is connected through multiple interfaces to a neighboring ONE/ONC Controller, only one NNI control-channel must be logically defined between these entities. - Availability of the NNI control-channel mechanism could be based on PPP Multi-link protocol or other protection mechanisms (TBD). To ensure the inter-operability between both in-band and out-of-band and out-of-network signaling mechanisms, the boundary ONE must act as a signaling relay entity. If the NNI control-channel is defined between an sub-network boundary ONE NNI interface and an ONC which implements the NNI functionality, then this boundary ONE must act as a relay entity for the signaling protocol. 4.2 NNI Signaling Transport Mechanisms In this proposal, the following signaling transport mechanisms are considered; for each of these signaling mechanisms, a specific transport mechanism has been defined: - In-band: signaling messages are carried over a control-channel embedded in the logical link between the NNI interfaces of the peering ONE controllers. The control-channel is implemented through the use of Optical Channel layer (OCh) overhead bytes [ITU-T G.709 v0.83] over which the NNI signaling channel is realized. For the SDH/Sonet particular case, the control-channel could be implemented through line DCC bytes or other SDH/Sonet unused overhead bytes. Papadimitriou et al. Expires May 2001 11 draft-papadimitriou-onni-frame-01.txt November 2000 - Out-of-band: signaling messages are carried over a control-channel embedded in the physical link between the NNI interfaces of the peering ONE controllers. The control-channel is implemented through the use of a dedicated wavelength included on a (D)WDM fiber link over which the NNI signaling channel is realized. This channel is referenced as the Optical Supervisory Channel (OSC). For the SDH/Sonet particular case, a TDM sub-channel can be allocated for realizing the NNI signaling channel. - Out-of-network: signaling messages are carried over a dedicated and separated network between NNI Agent interfaces of the peering ONC controllers or over a dedicated control-link between NNI interfaces of the peering ONE controllers. The dedicated physical- link is implemented through the use of one (or multiple) dedicated interface(s) over which the NNI signaling channel is realized. The framing used on top of the signaling control-channel could be the PPP protocol in HDLC-like framing [RFC 1662] or PPP protocol over SDH/Sonet [RFC 2615]. In case where the ONE (respectively ONC) is connected through multiple link to a neighboring ONE (respectively ONC), PPP Multilink could be the protocol used to carry the signaling messages over the control-channels between the NNI interfaces. The availability of the signaling transport mechanism is described in the next sub-section. 4.3 Availability of the Signaling Network We assume here that the signaling control-plane network is either explicitly configured or automatically discovered and selected through the following rules: first select the in-band signaling network, then select the out-of-band signaling network otherwise select the out-of-network signaling network. These rules depend on the signaling transport mechanism supported by the ONE. If a specific signaling transport mechanism is required by one (or both) of the neighboring ONEs, the signaling transport mechanism can be explicitly specified by the requestor. The explicit configuration can also include the backup signaling transport mechanism. 4.4 Security of the Signaling Network In order to increase the security level of the signaling between ONEs (respectively ONC), the use of a bi-directional Challenge Handshake Authentication Protocol (CHAP) is considered. Bi- directional (or symmetric) CHAP exchange between ONE controllers (respectively ONCs) is provided for the authentication of both peers constituting the end-points of the signaling control-channel. Other authentication protocols such as IPSEC Authentication Header or IPSEC Encrypted Payload mechanism could also be defined for the IP based signaling between Untrusted NNI interface. Papadimitriou et al. Expires May 2001 12 draft-papadimitriou-onni-frame-01.txt November 2000 5. Neighbor Discovery Protocol The key objective of the Neighbor Discovery Protocol (NDP) at the NNI is to provide the information needed to determine the neighbor identity (IPv4 address associated to the corresponding NNI) and neighbor connectivity over each link connecting internal ONEs or an internal ONE to a boundary ONE. The Neighbor Discovery Protocol is fundamentally an in-fiber mechanism. Within an in-fiber signaling transport mechanism, signaling messages are carried over a control-channel embedded either in the logical link or in the physical link between the NNI interfaces of the peering ONE. Consequently, the neighbor discovery protocol does not apply to centralized optical sub-network topologies. 5.1 Neighbor Discovery Protocol: Related concepts We first define the concepts considered in this and subsequent sections to describe the neighbor discovery protocol. To each of these concepts, an identifier is associate to enable the inter- operability: - A logical-port defines the logical structure of a physical port by identifying for a given port each of the channels included within this port and sub-channel included within this channel. - A logical-port ID identifies a logical-port. The logical-port ID is defined as the concatenation of the port-ID, channel-ID and the sub-channel ID. - An internal-point ID is defined as the concatenation of the logical-port ID and the IP address of the ONE to which this logical- port belongs. A logical-port can also be defined by using the G.MPLS terminology [G.MPLS] as follows: - a Time-Division Multiplex Capable interface - a Lambda Switch Capable interface - or a Fiber-Switch Capable interface So, in a first approach, this document does not consider an optical logical-port as a Packet-Switch Capable (PSC) interface since such optical interfaces do not recognize packet boundaries and are incapable of forwarding data based on the content of packet header. Hence, in the remaining sections of this document, an internal-point ID never identifies a PSC interface. Introduction of PSC interfaces is for further study. Consequently, by taking into account the proposed definitions, we have the following mapping between these definitions: - a logical-port identified by the port ID refers to Fiber-Switch Capable interface Papadimitriou et al. Expires May 2001 13 draft-papadimitriou-onni-frame-01.txt November 2000 - a logical-port identified by the port ID and the channel ID refers to a Lambda Switch Capable interface - a logical-port identified by the port ID, channel ID and sub- channel ID refers to a Time-Division Multiplex Capable interface If we extend these definitions to the client addressable logical- ports then a logical-port identified by a logical-address refers to a PSC interface. 5.2 Neighbor identity discovery The neighbor identity discovery is considered here for in-band and out-of-band signaling transport mechanism. 5.2.1 Basic identification-related discovery The physical port and identity discovery provides the following information to the ONE: - the ONE discovers the identity of the neighboring ONE by automatically discovering the IPv4 address assigned to the NNI interface - the ONE discovers the identity of the physical ports of each port connected to the neighboring ONE The knowledge of the IP address is the key to establish the NNI signaling control-channel between two neighboring ONEs. For the in-band, the proposed transport mechanism is based on the overhead bytes of the Optical Channel Sub-Layers (OPU Overhead bytes _ ODU Overhead bytes _ OTU Overhead bytes) as defined by [ITU-T G.709 v0.83]. For the SDH/Sonet particular case, the section DCC bytes or other SDH/Sonet unused overhead bytes. For the out-of-band, the proposed transport mechanism is based on a dedicated Optical Supervisory Channel (i.e. the control-channel) carried on the same physical link as the one carrying the data- channels. However, the OSC channel is only available at the IaDI-NNI but not at the IrDI-NNI. For the SDH/Sonet particular case, a TDM sub-channel can be entirely allocated for this purpose. 5.2.2 Additional Identification-related Discovery The Carrier ID (CID) defines the identity of the carrier to which the ONE element belongs. The Privacy ID (PrID) determines whether a NNI interface is untrusted or trusted. These identifiers are provisioned by the administrative authority of the optical network and exchanged during the neighbor identity discovery process: - ONE discovers the Carrier ID attached to a specific ONE element Papadimitriou et al. Expires May 2001 14 draft-papadimitriou-onni-frame-01.txt November 2000 - ONE discovers the Privacy ID attached to a specific ONE internal- point The Carrier ID uniquely determines the owner of a signaling message when travelling over IrDI-NNI signaling channels between optical networks. The Privacy ID makes the distinction between trusted and untrusted NNI interfaces: generally, there is a trust relationship between IaDI-NNI interfaces and an untrusted relationship between IrDI-NNI interfaces. The privacy level (trusted or untrusted) defines the confidentiality level of the information exchanged through the corresponding NNI interfaces. 6. NNI Topology and resource Distribution Protocol The Topology and resource Distribution Protocol (TrDP) is the mechanism provided to initially exchange and distribute the discovered logical-port related information of the ONE included in an optical sub-network. This protocol is fundamentally running across intra-domain NNI interfaces. The TrDP protocol is an IGP concept-based protocol. However, since the focus of this document is to enlarge the scope of the current available paradigms and concepts, we do not refer explicitly either to an existing extended routing protocol or to the need of a new IGP routing protocol. This means that the requirements detailed within this section must be applicable to any kind of existing IGP routing protocols. However, within the first version of this proposal, the specifications of this protocol implicitly refer to an OSPF-like protocol. Hence, through the remaining sections of this document, we use the term OSPF-Like protocol to refer to this routing protocol. The TrDP protocol is based on the following concepts: - maintaining the neighbor relationship with peering ONEs - flooding of the ONEs logical link adjacencies - flooding of the ONEs logical link state - flooding of the ONEs logical link related information These information are used to maintain three databases: the neighbor database, the local ONE database and the topology ONE database. Depending on the flooding scope, the ONE information distributed throughout the optical sub-network is related to: - the logical-port identification information, - the logical-port resource information (available and reservable bandwidth as well as the associated priority), - the logical-link service and routing information (protection level(s) and the associated priority as well as the internal link diversity) Papadimitriou et al. Expires May 2001 15 draft-papadimitriou-onni-frame-01.txt November 2000 For the ONE termination-point, one additional information is flooded throughout the optical sub-network: the logical address to termination-point ID mappings. 6.1 Transport mechanisms A transport mechanism is provided between IaDI-NNI interfaces to enable the distribution of the topology information within or between optical sub-networks. These transport mechanisms are the same than those defined for the NNI signaling and described in section 4. Other specific transport mechanisms related to the TrDP protocol are TBD. 6.2 Protocol requirements The Topology and resource Distribution Protocol (TrDP) requirements are related to those imposed for NNI signaling and control-channels. For each of those requirements, the corresponding mechanism to fulfil these requirements is specified: - Between the IaDI-NNIs, the TrDP protocol must be IP-based, the NNI IPv4 address is the one uniquely associated to the internal or boundary ONE. The knowledge of the NNI IPv4 address could be static or dynamic. - Availability and maintenance of the neighbor relationships that define the adjacencies between ONEs is provided by a `classic' version of the Hello protocol including flow-control and checksum. - Reliability of the TrDP protocol is provided by means of a sequenced acknowledgement mechanism. - Reliability of the information flooded could be based on the use of an aging-time, a payload checksum, a flow-control mechanism based on packet sequence numbering and the identification of the source ONE and the identification of the point this payload describes. - The time to acquire the consistency of the topology database within a given optical sub-network and convergence time during `topological modifications' should be reduced in order to allow rapid changes within the optical sub-network. - The authentication mechanism provided between peering ONE's constituting a neighbor relationship within a given instance of the TrDP protocol, could be based on the Message Digest 5 authentication process. - The confidentiality of the information flooded throughout the network can be achieved by encrypting the IP packet payload. Papadimitriou et al. Expires May 2001 16 draft-papadimitriou-onni-frame-01.txt November 2000 In addition to these requirements, the topology distribution protocol must meet the requirements already defined for the NNI control-channels. 6.3 TrDP Discovery Protocol The TrDP protocol is closely related to the Neighbor discovery protocol and includes the following basic discovery mechanisms: - Logical-port resource discovery (section 6.3.1) - Logical-port address discovery (section 6.3.2) - Logical-port service discovery (section 6.3.3) The concepts and terminology concerning the logical-port and internal-point are the same the one defined in the section 5.1. 6.3.1 Logical-port: Resource Discovery The logical-port resource discovery process is defined as the mechanism provided to exchange the information related to the identification and the available resources for all of the logical ports connecting two neighboring ONEs. The proposed mechanism implicitly includes the logical-port identity registration process since each of the logical-ports sends its corresponding identifier during the same process. The logical-port resource discovery process includes Framing- Bandwidth capacity of each of the logical-ports connecting two neighboring ONEs and for TDM capable interfaces the transparency- level supported by the ONE logical-ports. The NNI signaling transport mechanisms considered here are the in- band (case 1) and the out-of-band (case 2) mechanisms; extensions for the out-of-network (case 3) mechanisms are also considered. Case 1: In-band transport The Framing-Bandwidth resource discovery process is realized by means of a PPP over HDLC-like framing [RFC 1662] session established between the ONEs NNI interfaces. The corresponding mechanism should include the following steps: - During this PPP session, the Framing-Bandwidth capacity of each of the logical-ports connecting neighboring ONEs is exchanged between the source ONE and the destination ONE. If the generic logical structure of a physical port does not include channel (i.e. fiber-switch capable port) or sub-channel (i.e. lambda-switch capable port) the corresponding identifiers are not specified. Papadimitriou et al. Expires May 2001 17 draft-papadimitriou-onni-frame-01.txt November 2000 - The response about the Framing-Bandwidth of each logical-port are directed from the destination ONE to the source ONE. The proposed mechanism implicitly includes the Internal-point Identity registration process since each of the logical-port information is sent with its corresponding identifier (i.e. the internal-point identifier including the ONE IPv4 address to which the logical-port belongs) during the same process. Case 2: Out-of-band transport The mechanism described in the previous case needs an additional identifier since the out-of-band mechanism must know the port ID to which the records refers. The concept is the same as the one described in the previous case. However in order to distinguish between the framing-bandwidth capacity of each of the registered ports, a list containing the physical port identification is sent from the source ONEm NNI interface to the destination ONEn NNI interface. The response sent by the destination ONE and directed to the source ONE contains a list containing the Framing-Bandwidth of each logical-port included within the physical connecting peering ONEs. Consequently, and compared to the previous case, only one additional information (the port ID correspondence) per port must be provided between the ONEs. Case 3: Out-of-Network Extensions All the processes described here except the Internal-port registration process can be extended to the out-of-network signaling transport by considering one additional hierarchy level: the first level refers to the IP address of the IaDI-NNI connected to the neighboring IaDI-NNI and the second level to the ONE-to-ONE port correspondence. - Additional Resource-related Discovery - Some parameters, such as the SDH/SONET transparency level and the support of concatenation (virtual or continuous concatenation) could be exchanged for TDM capable ports during the Logical-port Resource Discovery process. Concerning the G.LSP directionality, we do not consider the exchange of information related to the support of bi-directional G.LSPs. 6.3.2 Logical-port: Address Discovery Internal-point identifiers may be addressed through the use of logical addresses. Such kind of mechanism has already been defined Papadimitriou et al. Expires May 2001 18 draft-papadimitriou-onni-frame-01.txt November 2000 for the addressing of the client CNE termination-point identifiers [OIF2000.261.1]. However, this proposal does not in its current version consider the logical addressing of logical-ports. 6.3.3 Logical-port: Service Discovery Logical-port Service Discovery is the last step included in the TrDP discovery protocol. Transport mechanisms for the logical-port service discovery are the same than those defined during for the previous logical-port resource discovery. An in-band or out-of-band IP over PPP session between the NNI interfaces of neighboring ONEs could be the transport mechanism used by the logical-port service discovery. The logical-port service discovery mechanism provides the following information through the signaling channel set up between NNIs of neighboring ONEs: 6.3.3.1 Link-Protection Service Discovery During the link-protection service discovery process, neighboring ONEs exchange the information related to link-protection level supported by their directly connected logical-ports. The related information is initially manually provisioned and then exchanged. Link-Protection levels could be one (or more than one) of the following: - Unprotected 0:1 - Dedicated 1+1 Protection - Dedicated 1:1 Protection - Shared Protection: 1:N - M:N Link-Protection level implicitly refers to the protection levels associated to the data-channel links between two neighboring ONEs. Consequently, per data-channel direction, we consider one source link-protection level (for the transmit direction) and one destination link-protection level (for the receive direction). The corresponding discovery process occurs between two neighboring ONEs and includes a request/response through which the peering ONEs exchange their supported logical-port protection levels. After this discovery process, a `reservation' process requested between neighboring ONEs may be considered. The corresponding detailed mechanism is TBD. 6.3.3.2 Link-Priority Service Discovery During the link-priority service discovery process, the neighboring ONEs exchange the following priority-related service parameters: Papadimitriou et al. Expires May 2001 19 draft-papadimitriou-onni-frame-01.txt November 2000 1. Link-Priority (and priority classes) and Link-Preemption type (setup and recovery) supported by the ONEs are exchanged during the Link-Priority service discovery. The link-priority concept is associated to: - the available bandwidth per port, per channel or per sub-channel and the bandwidth reservation during the G.LSP creation process. - the link protection level per port supported by the ONE During the G.LSP creation process, the available bandwidth reserved for the G.LSP during this process is related to the bandwidth priority of the link through which the lighpath is created. The same mechanism takes place for the protection level requests during the G.LSP creation process. The priority of a link could belong to a link priority-class. For the ONEs that do not support the priority-class processing, the link priority must be set to a default link priority class (Class 1) [ENH-LSPS]. For the ONEs, which do not support the link priorities and the link priority-class processing, a default link priority must also be defined. These default values are defined in order to ensure the interoperability between ONEs at IaDI-NNI interfaces and between optical sub-networks at IrDI-NNI interfaces. Note: if the link-priority service is not supported by an ONE, the link-priority classes service won't be supported by this ONE. 2. Preemption (i.e. pre-emptability) of a link is related to the priority of the link. Preemption type includes the setup (or creation) preemption, the recovery preemption as both the setup and recovery preemption the pre-emptability of a G.LSP. The corresponding mechanism specifies whether a given link used by a lower-priority G.LSP can be preempted by a G.LSP of higher priority if the resource used by the lower-priority G.LSP need to be used during the setup and/or the recovery of this higher priority G.LSP. 6.3.3.3 Routing-related Service Discovery The routing-related service discovery is mainly based on the diversity-related options support of the boundary and internal ONEs: The diversity of a G.LSP is defined as the list of N G.LSPs ID from which a given G.LSP (so a given G.LSP ID) must be physically diverse from. Several type of resource from which a given G.LSP could be physically diverse from are defined. These resources have their counter-parts within the optical network. Each ONE included into an Papadimitriou et al. Expires May 2001 20 draft-papadimitriou-onni-frame-01.txt November 2000 optical network could support the following resources from which a given G.LSP must be diverse from: - Fiber segments - Fiber sub-segments - Fiber links - Shared Risk Link Group (SRLG) When executing the G.LSP service request from the client CNE (remind here that the client CNE does only knows about the G.LSPs he has already established) the client CNE can only reference a G.LSP M from which the new G.LSP N should be diverse. The ONE will interpret this request by considering the Shared Risk Link Group _ SRLG of the G.LSP M and find a physical route for the G.LSP N whose SRLG is diverse from. The associated discovery mechanism is straightforward: the ONE supports or does not support SRLG diversity. However, the corresponding detailed mechanisms are currently under definition. 6.4 TrDP Protocol Mechanisms A dedicated mechanism is considered here to distribute the topological information discovered through the TrDP discovery protocol. The topology distribution protocol is based on a reliable flooding of the ONE state, information and adjacencies into the optical sub-network. Since the ONE's adjacencies are discovered through the neighbor distribution protocol, they control the distribution of the topological information of the optical sub-network. The ONE's advertisements fully describe or summarize the discovered information of the ONE's logical-ports. The topology database is the collection of all ONE's advertisements. 6.4.1 ONE Advertisements and Flooding Process Each ONE belonging to an optical sub-network originates ONE advertisements. These advertisements describe the state and information related to the ONE's logical-ports (i.e. ONE logical- links). All of the ONE logical links must be described in a single ONE advertisement. Inside an optical network (i.e. Autonomous System), three types of ONE advertisements are considered: link-local, intra-area and inter- area ONE advertisements; a flooding rule is associated to each of these ONE advertisements: - Link-local ONE advertisements: flooding scope limited to adjacent ONEs - Intra-area ONE advertisements: flooding scope limited to an area - Inter-area ONE advertisements: flooding scope covers a whole autonomous-system Papadimitriou et al. Expires May 2001 21 draft-papadimitriou-onni-frame-01.txt November 2000 The flooding mechanism of the TrDP protocol distributes and synchronizes the local ONE database and the topology database between ONE IaDI-NNI interfaces. The topological information flooded throughout the optical sub- network is related to the logical-port properties-related information and their associated logical-links: - the logical-port identifier (which populates only the local ONE database) - the logical-port resource: available and reservable bandwidth (minimum and maximum) as well as the associated priority level(s) - the logical-link protection level(s) and the associated priority level(s) - the link diversity (the SRLG groups included within the link to which the corresponding ONE internal-point belongs to) - and for logical-ports corresponding to ONE termination-points, the mapping between the ONE termination-point identifier and the corresponding CNE logical address 6.4.2 Topology Database and Local ONE Database The collected ONE advertisements of all ONEs included within the optical sub-network constitutes the topology database. The consistency of the topology database is directly related to the consistency of the information flooded through the ONE advertisements and the frequency at which these advertisements are generated. In turn, these criteria determine the convergence time of the topology database throughout a given optical sub-network. The consistency of the topology database is not directly related to the performance of the NNI signaling channels. Once the goodput of these signaling channels is known and advertisement frequency has been configured, the performance of the signaling channel does not play a role anymore concerning the consistency of this database. The detailed information concerning the logical-ports properties and features and exchanged between directly connected ONEs, constitutes the local ONE database: 1. Logical-port The restriction of the topology database to the complete information related logical-port and their corresponding links gives a logical view of the optical network physical links between ONEs. The detailed information related to logical-ports connecting peering ONEs forms the local ONE database. Within the local ONE database, the identity parameters are related to the state of the corresponding logical-port and adjacency. Consequently, the corresponding state is determined whether or not the logical-port is active or inactive. Papadimitriou et al. Expires May 2001 22 draft-papadimitriou-onni-frame-01.txt November 2000 Moreover, a G.LSP could be represented as a set of logical-port IDs and thus as a set of internal-point IDs (concatenation of the ONE IP Address and Logical-port ID) starting from the source termination- point ID and terminating at the destination termination-point ID: [{TP-Id _ IP-Id},{IP-Id _ IP-Id},_,{IP-Id _ IP-Id},{IP-Id _ TP-Id}] Consequently, the topological information related to the logical- ports, flooded within the link-local ONE advertisements, is the following: - the logical-port identifier (i.e. logical-link identifier) and its status - the G.LSP identifier (the set of internal-point IDs) and its corresponding status Since the collected ONE advertisements of all neighboring ONEs included into the same optical sub-network constitutes the local ONE database, this database has the following entries when the logical- port identity discovery process is convergent: Local ONE Neighbor ONE 1 State --------------------------------------------------------------- Logical-port ID Logical-port ID Active Logical-port ID Logical-port ID Inactive Local ONE Neighbor ONE N State --------------------------------------------------------------- Logical-port ID Logical-port ID Active Logical-port ID Logical-port ID Inactive After the initial convergent state, an ONE update will only be generated in the following cases: - the status of the logical-port has changed - the status of the G.LSP using this logical-port has changed 2. Logical-port Resource Within the local ONE database, the logical-port resource-related information includes the available bandwidth (AB) and the minimum and maximum Reservable Bandwidth (MinRB and MaxRB) as well as the associated priority (AB[p], MinRB[p] and MaxRB[p]). The priority value is the lowest priority at which this bandwidth is available. This resource-related information is available in the local ONE database for each of the logical-ports connected to direct peer ONEs. So, the logical-port resource information is represented by the following entries into the local ONE database: Local ONE Neighbor ONE 1 State -------------------------------------------------------------------- LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active Papadimitriou et al. Expires May 2001 23 draft-papadimitriou-onni-frame-01.txt November 2000 LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Inactive Local ONE Neighbor ONE 2 State -------------------------------------------------------------------- LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active In these database entries: - AB values are defined as the framing-bandwidth parameter - RB values are defined as the framing-bandwidth parameter When the boundary ONE receives a G.LSP create request, and the CSPF has established the corresponding path into the optical sub-network, the boundary ONE waits until receiving the G.LSP create response message to update the local database and flood the ONE updates throughout the optical sub-network. For instance, if the G.LSP is requested with 1 unit of bandwidth and with priority r then the local database is updated as follows: Local ONE Neighbor ONE 1 -------------------------------------------------------------------- LP-ID AB-1[p] MinRB[p] MaxRB-1[p] LP-ID AB-1[q] MinRB[q] MaxRB-1[q] LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] If an additional G.LSP create request with 4 units of bandwidth and a 4:1 relationship exists between the local and the neighbor ONE, then the local database is updated as follows: Local ONE Neighbor ONE 2 -------------------------------------------------------------------- LP-ID AB-1[p] MinRB[p] MaxRB-1[p] LP-ID AB-4[q] MinRB[q] MaxRB-4[q] LP-ID AB-1[p] MinRB[p] MaxRB-1[p] LP-ID AB-1[p] MinRB[p] MaxRB-1[p] LP-ID AB-1[p] MinRB[p] MaxRB-1[p] 3. Logical-link Protection The related mechanisms are TBD. 4. Link Diversity The related mechanisms are TBD. 6.4.3 Flooding Rules To avoid an exponential increase of the ONE advertisements through the optical network, the following flooding rules are applied: Papadimitriou et al. Expires May 2001 24 draft-papadimitriou-onni-frame-01.txt November 2000 1. Flooding link-local advertisements Link-local advertisements are flooded only between neighboring ONE. The information included within the corresponding ONE advertisement determines for any logical-link connected to a given neighbor: - the logical-link identification: the IPv4 address of the ONE and the identifier to which the local logical-port is connected - the logical-link resource: available bandwidth, minimum and maximum reservable bandwidth and the associated priority - the logical-link services: protection and the associated priority _ diversity support for the corresponding link For the logical-links corresponding to ONE termination-points, one additional information is flooded throughout the optical sub- network: the reachability information which includes the client CNE logical address corresponding to this termination-point. Consequently, the ONE has the complete information concerning the identity, the resources and the services offered by the neighboring ONE logical links. This information constitutes the local ONE database (cf. Section 6.4.2). 2. Flooding intra-area advertisements For each of the ONE's adjacency, one intra-area ONE advertisement is generated and flooded within the corresponding area. The information included in this ONE advertisement is summarized as follows: within an intra-area ONE advertisement, the logical-links (logical-port[n]) are grouped regarding the common resource and service properties they share: - Unreserved Bandwidth: AB[p] _ Sum(Reserved Bandwidth[p]) - Min Reservable Bandwidth: MinRB[p] - Associated Link Protection level: Protection[p] - Preemption types supported: Setup and/or Recovery - Routing diversity-related information For boundary ONE, the intra-area advertisement also includes the CNE termination-point ID (and logical address to CNE termination-point ID mapping) and the associated status. 3. Flooding inter-area advertisements For each area one inter-area ONE advertisement is generated and flooded within the corresponding autonomous-system. The information included in this ONE advertisement is summarized as follows: within the inter-area advertisement, logical-links (logical-port[n]) are grouped by considering the common resource and service properties they share, except the routing diversity-related information: - Unreserved Bandwidth: AB[p] _ Sum(Reserved Bandwidth[p]) - Min Reservable Bandwidth: MinRB[p] - Associated Link Protection level: Protection[p] - Preemption types supported: Setup and/or Recovery Papadimitriou et al. Expires May 2001 25 draft-papadimitriou-onni-frame-01.txt November 2000 In this case, the routing diversity-related information is not included within the corresponding advertisement. A summarization of the routing diversity-related information is TBD. By classifying the advertisement types, the amount of information flooded within an area and an autonomous-system is drastically lower than the amount of information to be flooded without such summarization of the information. 6.4.4 ONE Advertisement Type We can define in addition to source ONE and destination ONE the following terms: - the intermediate ONE: ONE included within an area or an area border ONE; this ONE corresponds to an internal ONE including only IaDI-NNI interfaces - the boundary ONE: autonomous-system border ONE; this ONE corresponds to an ONE containing at least one IrDI-NNI interface The ONE advertisement type includes the distribution mechanism for flooding the corresponding information throughout a given optical sub-network (or network depending on the type of advertisement). The ONE advertisement type of the ONE advertisement identifies the advertisement's range of topological distribution. This range is referred to as the Flooding Scope. The ONE advertisements have a flooding scope associated with them so that the scope of flooding may be link-local (type 1), intra-area (type 2) or the entire autonomous-system (type 3). The flooding scope of each of the ONE advertisement types are: - The type-1 denotes a link-local scope. ONE advertisements with a link-local scope are not flooded beyond the local IaDI-NNI link - The type-2 denotes an intra-area scope. ONE advertisements with a intra-area scope are not flooded beyond the area where they are originated. - The type-3 denotes an inter-area (or AS-wide) scope. ONE advertisements with an inter-area scope can be flooded throughout the entire Autonomous System. 6.4.5 Additional mechanisms The Topology distribution protocol could also include the following mechanism: - If we consider that the IP control plane signaling protocol (cf. Section 7) is based on CR-LDP Label Request (or RSVP Path message) and Label Mapping messages (or RSVP Resv message) then label piggybacking could be included in the proposed version of the TrDP Protocol. Papadimitriou et al. Expires May 2001 26 draft-papadimitriou-onni-frame-01.txt November 2000 - Other additional mechanisms are TBD. 7. NNI Signaling Mechanisms and Protocols This section describes the NNI signaling mechanism needed internally to the optical network in order to provide the optical network clients the G.LSP signaling services at the UNI. We first remind the UNI G.LSP signaling services, then consider the NNI signaling requirements and the potential NNI signaling protocols and finally detail the NNI signaling messages. 7.1 UNI G.LSP Signaling Services As defined into [MPLS-OUNI] and the UNI v1.0 OIF proposal [OIF200.125.2], four G.LSP signaling services are considered: - G.LSP creation - G.LSP modification - G.LSP deletion - G.LSP status Additionally, the UNI-N may send a G.LSP notification message to notify the UNI-C about the current status of a G.LSP. This G.LSP notification message as to be considered has an unsolicited message. For each of these services, the following primitives should be available: - Request messages: . G.LSP create request message . G.LSP modify request message . G.LSP delete request message . G.LSP status request message - Response messages: . G.LSP create response message . G.LSP modify response message . G.LSP delete response message . G.LSP status response message - Unsolicited messages: G.LSP notification Note that the G.LSP status service could be initiated either by Client UNI (UNI-C) or by Network UNI (UNI-N). 7.2 NNI Signaling Requirements NNI Signaling requirements are related to the requirements imposed for in-band, out-of-band and out-of-network NNI control-channels. For each of those requirements, the corresponding mechanism to fulfil these requirements is specified: - Between the NNI interfaces, the signaling protocol must be IP- based, the NNI IPv4 address is the one uniquely associated to the Papadimitriou et al. Expires May 2001 27 draft-papadimitriou-onni-frame-01.txt November 2000 internal or boundary ONE (respectively ONC) corresponding interface. The knowledge of the NNI IPv4 address could be static or dynamic. - When ONE (respectively ONC) is connected through multiple interfaces to a neighboring ONE (i.e. there are multiple in-band and/or out-of-band links between the corresponding ONEs or multiple out-of-network transport links between the corresponding ONCs), only one NNI signaling -channel must be logically defined between ONEs signaling interfaces (respectively ONC signaling interfaces). - Availability of the NNI signaling-channel mechanism is based on PPP Multilink protocol for in-band/out-of-band channels and a dedicated mechanism (TBD) for out-of-network channels. - Reliability of the NNI signaling-channel mechanism is provided through the use of a dedicated TCP/IP session on top of a PPP Multilink session if supported by the peering ONE equipment (respectively ONC equipment). - The security of the NNI signaling-channel and interfaces is provided through the use of CHAP protocol and IPSEC header authentication (and optionally encryption). Security-level of the NNI signaling-channels and interfaces depends on the relationship between peering ONEs (resp. ONC) i.e. whether the NNI signaling channel is established between untrusted or trusted interfaces. - The performance of the NNI signaling -channel must be guaranteed through the definition of a minimum round-trip time for a given payload size. Control of the NNI signaling -channel performance is greatly facilitated by the use of the TCP Protocol. 7.3 NNI Signaling Paradigm and Protocols The signaling paradigm considered implicitly throughout this document is based on the G.MPLS signaling concept. However, we do not refer to a specific implementation of the paradigm in order to keep the focus of this document on a higher level than the one proposed in the [G.MPLS] draft. However, since of the aim of the proposal is to determine which requirements and mechanisms does the G.MPLS signaling protocol and its implementation need to fulfil we do refer to specific functional aspects included within the available specifications. This proposal considers the constraint-based extension of the label distribution protocol (CR-LDP) and the Resource reSerVation Protocol (RSVP) including its Traffic-Engineering extensions (RSVP-TE) as potential NNI signaling protocol implementations. 7.4 NNI Signaling Interfaces Papadimitriou et al. Expires May 2001 28 draft-papadimitriou-onni-frame-01.txt November 2000 This section defines the NNI signaling interfaces. In order to describe these messages and the corresponding mechanisms, we define the following concepts for a given G.LSP service request/response: - Source IaDI-NNI: the source IaDI-NNI is defined as the IaDI-NNI interface belonging to the ONE (or ONC) whose UNI-N has the source UNI-C as client. The source IaDI-NNI sends the G.LSP service message within the optical sub-network. - Destination IaDI-NNI: the destination IaDI-NNI is defined as the IaDI-NNI interface belonging to the ONE (or ONC) whose UNI-N has the destination UNI-C as client. The destination ONE is the receiver of the G.LSP service message within the optical sub-network. - Intermediate IaDI-NNI: the intermediate IaDI-NNI interface is defined as the IaDI-NNI interface belonging to an ONE (or ONC) which does not include any UNI-N interface. - Boundary IaDI-NNI: the boundary IaDI-NNI interface is a particular case of an intermediate IaDI-NNI interface belonging to an ONE (or ONC) which includes a IrDI-NNI interface. - Source IrDI-NNI: the IrDI-NNI interface belonging to a boundary ONE (or ONC) included within the optical network including the source IaDI-NNI interface. - Destination IrDI-NNI: the IrDI-NNI interface belonging to a boundary ONE (or ONC) included within the optical network including the destination IaDI-NNI interface. - Intermediate IrDI-NNI: the IrDI-NNI interface belonging to a boundary ONE (or ONC) included within an optical network which does include neither the source IrDI-NNI interface nor the destination IrDI-NNI interface. This proposal covers both distributed and centralized approaches. For the latter, the mappings between the kind of NNI interface and the centralized model are defined by considering a unique ONC controller per optical sub-network. For the centralized model we have the following equivalence between ONC and their supported interfaces (= means on _same ONC including_): - Intra-domain signaling within an optical network: Source IaDI-NNI = Intermediate IaDI-NNI = Destination IaDI-NNI - Inter-domain signaling between optical networks Source IaDI-NNI = Intermediate IaDI-NNI (sub-network 1) _ Intermediate IaDI-NNI (sub-network i) = Source IrDI-NNI (sub- network i) _ Destination IrDI-NNI (sub-network j) = Intermediate IaDI-NNI (sub- Papadimitriou et al. Expires May 2001 29 draft-papadimitriou-onni-frame-01.txt November 2000 net j) _ Intermediate IaDI-NNI (sub-network n) = Destination IaDI-NNI (sub- net n) 7.5 NNI Signaling Messages This section defines the NNI signaling messages. In order to describe these messages and the corresponding mechanisms, we describe the corresponding signaling message directions. To each of the UNI signaling message corresponds at least one NNI signaling message. The mapping of these messages into their NNI counter-part and their associated directionality are described in the next sub-sections. 7.5.1 G.LSP Creation The G.LSP creation process includes the G.LSP create request and the G.LSP create response. 7.5.1.1 G.LSP create request When located within a given optical sub-network or between optical sub-networks, the lightpath create request message is routed through the following generic paths: - UNI: Source UNI-C -> UNI-N - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI - UNI: UNI-N -> Destination UNI-C The following figure describes the G.LSP create request message sent by the initiating UNI-C to the UNI-N and the corresponding message sent by the initiating IaDI-NNI interface after the treatment performed on this message. The latter message also corresponds to the one sent between intermediate IaDI-NNI interfaces and between IrDI-NNI interfaces. +-------------------------------+ | ONE Source | | Termination-point ID | +-------------------------------+ | ONE Destination | | Termination-point ID | +-------------------------------+ +-------------------------------+ | CNE Source | | Explicit Route | | Termination-point ID | | | +-------------------------------+ +-------------------------------+ | CNE Destination | | Record Route (optional) | | Termination-point ID | | | +-------------------------------+ +-------------------------------+ Papadimitriou et al. Expires May 2001 30 draft-papadimitriou-onni-frame-01.txt November 2000 | Source User Group ID | | Source User Group ID | +-------------------------------+ +-------------------------------+ | Destination User Group ID | | Destination User Group ID | +-------------------------------+ +-------------------------------+ | Contract ID (optional) | | Carrier ID (optional) | +-------------------------------+ +-------------------------------+ | G.LSP ID | | G.LSP ID | +-------------------------------+ +-------------------------------+ | Bandwidth-Framing | | Bandwidth-Framing | +-------------------------------+ +-------------------------------+ | SDH/SONET Options (optional) | | SDH/SONET Options (optional) | +-------------------------------+ +-------------------------------+ | Optical (optional) | | Optical (optional) | +-------------------------------+ +-------------------------------+ | Directionality (optional) | | Directionality (optional) | +-------------------------------+ +-------------------------------+ | Max Signaling Delay (optional)| | Max Signaling Delay (optional)| +-------------------------------+ +-------------------------------+ | Priority-Preemption (optional)| | Priority-Preemption (optional)| +-------------------------------+ +-------------------------------+ | Network Protection (optional) | | Network Protection (optional) | +-------------------------------+ +-------------------------------+ | Side Protection (optional) | | Side Protection (optional) | +-------------------------------+ +-------------------------------+ | Diversity (optional) | | Diversity (optional) | +-------------------------------+ +-------------------------------+ | Service-related (optional) | | Service Related (optional) | +-------------------------------+ +-------------------------------+ Figure 4: G.LSP Create request Within this figure, the following parameters have a specific significance: - the SDH/SONET parameter is only mandatory for SDH/SONET - the Max Signaling Delay is defined as the Maximum Signaling Request Delay - the explicit route parameter is detailed in section 7.6.2 - the record route parameter is detailed in section 7.6.3 The carrier ID, the diversity and the service-related parameters are only used to set up G.LSPs whose destination termination-point ID are located in another administrative domain than one to which the source termination-point ID belongs need to be established. Consequently the generic G.LSP create request message sent between IaDI-NNI interfaces includes the following parameters: - ONE Source Termination-point ID - ONE Destination Termination-point ID - Explicit Route - Record Route (optional) - Source User Group ID - Destination User Group ID Papadimitriou et al. Expires May 2001 31 draft-papadimitriou-onni-frame-01.txt November 2000 - G.LSP ID - Bandwidth-Framing - SDH/SONET Options (optional) - Optical Options (optional) - Directionality (optional) - Max Signaling Delay (optional) - Priority-Preemption (optional) - Network Protection (optional) - Side Protection (optional) Notice: some of these parameters are still under study (mainly concerning the priority-preemption and protection parameters) 1. Intra-Domain - G.LSP Creation Procedure The G.LSP creation procedure includes the procedure performed by the source, the intermediate and the destination IaDI-NNI interfaces. The main tasks to be performed by the source IaDI-NNI are: - calculate the route from the source ONE to the destination ONE by using the Constraint-Based Shortest Path First C-SPF Algorithm. - replace the CNE source and destination termination-point ID by ONE source and destination Termination-Point ID. - assign the identifier of the G.LSP and prepare the requested resources as indicated within the client request. The main tasks to be performed by the intermediate IaDI-NNI are: - prepare the requested resource as indicated within the G.LSP create request - remove the previous hop identifier included within the explicit route field and optionally append this value to the route record field The main tasks to be performed by the destination IaDI-NNI are: - replace the ONE source and destination termination-point ID by the CNE source and destination termination-point ID before forwarding the request to the corresponding client - remove the previous hop identifier included within the explicit route field and optionally append this value to the route record field - optionally register the route record field - prepare the requested resource as indicated within the G.LSP create request 2. Inter-domain G.LSP Creation Procedure The G.LSP creation procedure should include the following steps: - Since the create request message may be sent over IrDI-NNI interfaces (meaning through separate administrative authority and thus between optical networks) some CAC control should be provided at the boundary ONE to control the identity (by means of the Carrier ID) of the requestor. Papadimitriou et al. Expires May 2001 32 draft-papadimitriou-onni-frame-01.txt November 2000 Other mechanisms are TBD. 7.5.1.2 G.LSP create response The G.LSP create response is directed from the destination UNI-C to the source UNI-C through the following sequence: - UNI: Destination UNI-C -> UNI-N - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI - UNI: UNI-N -> Source UNI-C The following figure describes the G.LSP create response message sent by the terminating UNI-C to the UNI-N and the corresponding message sent by the terminating IaDI-NNI after the treatment performed on this message: +-------------------------------+ | ONE Source | | Termination-point ID | +-------------------------------+ +-------------------------------+ | CNE Source | | ONE Destination | | Termination-point ID | | Termination-point ID | +-------------------------------+ +-------------------------------+ | CNE Destination | | Record Route (optional)* | | Termination-point ID | | | +-------------------------------+ +-------------------------------+ | Source User Group ID | | Source User Group ID | +-------------------------------+ +-------------------------------+ | Destination User Group ID | | Destination User Group ID | +-------------------------------+ +-------------------------------+ | Contract ID (optional) | | Carrier ID (optional) | +-------------------------------+ +-------------------------------+ | G.LSP ID | | G.LSP ID | +-------------------------------+ +-------------------------------+ | Result Code | | Result Code | +-------------------------------+ +-------------------------------+ Figure 5: G.LSP Create response * The route record parameter is detailed in section 7.6.3. 7.5.2 G.LSP Deletion The G.LSP deletion process includes the G.LSP delete request and the G.LSP delete response. 7.5.2.1 G.LSP delete request The G.LSP delete request is directed from the source UNI-C to the destination UNI-C through the following sequence: Papadimitriou et al. Expires May 2001 33 draft-papadimitriou-onni-frame-01.txt November 2000 - UNI: Source UNI-C -> UNI-N - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI - UNI: UNI-N -> Destination UNI-C The following figure describes the G.LSP delete request message sent by the initiating UNI-C to the UNI-N and the corresponding message sent by the initiating IaDI-NNI interface after the treatment performed on this message. This message also corresponds to the one sent between intermediate IaDI-NNI interfaces and between IrDI-NNI interfaces. +-------------------------------+ +-------------------------------+ | CNE Source | | ONE Source | | Termination-point ID | | Termination-point ID | +-------------------------------+ +-------------------------------+ | CNE Destination | | ONE Destination | | Termination-point ID | | Termination-point ID | +-------------------------------+ +-------------------------------+ | Contract ID (optional) | | Explicit Route* | +-------------------------------+ +-------------------------------+ | G.LSP ID | | Carrier ID (optional) | +-------------------------------+ +-------------------------------+ | Result Code | | G.LSP ID | +-------------------------------+ +-------------------------------+ | Result Code | +-------------------------------+ Figure 6: G.LSP Delete request * Within the G.LSP delete request, the explicit route is implicitly defined by the G.LSP identifier since the intermediate ONEs keep track of the route established for the corresponding G.LSP. 1. Intra-Domain - G.LSP Delete Procedure The G.LSP Delete procedure and other related mechanism are TBD. 2. Inter-Domain - G.LSP Delete Procedure Since the delete message may be sent over IrDI-NNI interfaces (meaning through separate administrative authority and thus between optical networks) some CAC control should be provided at the boundary ONE to control the identity (by means of the Carrier ID) of the requestor. Other mechanisms are TBD. 7.5.2.2 G.LSP delete response Papadimitriou et al. Expires May 2001 34 draft-papadimitriou-onni-frame-01.txt November 2000 The G.LSP delete request is directed from the destination UNI-C to the source UNI-C through the following sequence: - UNI: Destination UNI-C -> UNI-N - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI - UNI: UNI-N -> Source UNI-C The following figure describes the G.LSP delete response message sent by the terminating UNI-C to the UNI-N and the corresponding message sent by the terminating IaDI-NNI after the treatment performed on this message: +-----------------------------+ +---------------------------------+ | CNE Source | | ONE Source | | Termination-point ID | | Termination-point ID | +-----------------------------+ +---------------------------------+ | CNE Destination | | ONE Destination | | Termination-point ID | | Termination-point ID | +-----------------------------+ +---------------------------------+ | G.LSP ID | | G.LSP ID | +-----------------------------+ +---------------------------------+ | Result Code | | Result Code | +-----------------------------+ +---------------------------------+ Figure 7: G.LSP Delete response The G.LSP delete request could also be generated by an IaDI-NNI during the creation (or recovery) of a high-priority G.LSP requesting some of the resources used by the low-priority G.LSP. This case is analyzed is the next section of this proposal. 7.5.3 G.LSP Modification The G.LSP modification process includes the G.LSP modify request and the G.LSP modify response. Since this process must be non-destructive, it must be strictly controlled in order to allow only modifications concerning specific G.LSP parameters as G.LSP priority value, user-group identifier and maximum signaling delay. 7.5.3.1 G.LSP modify request The G.LSP modify request is directed from the source UNI-C to the destination UNI-C through the following sequence: - UNI: Source UNI-C -> UNI-N - NNI: Source IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI - UNI: Intermediate UNI-N -> Destination UNI-C Papadimitriou et al. Expires May 2001 35 draft-papadimitriou-onni-frame-01.txt November 2000 The following figure describes the G.LSP modify request message sent by the initiating UNI-C to the UNI-N and the corresponding treatment performed on this message at the IaDI-NNI: +-------------------------------+ | G.LSP ID | +-------------------------------+ +-------------------------------+ | G.LSP ID | | Explicit route | +-------------------------------+ +-------------------------------+ | Contract ID (optional) | | Carrier ID (optional) | +-------------------------------+ +-------------------------------+ | Bandwidth-Framing (optional) | | Bandwidth-Framing (optional) | +-------------------------------+ +-------------------------------+ | SDH/SONET Options (optional) | | SDH/SONET Options (optional) | +-------------------------------+ +-------------------------------+ | Optical (optional) | | Optical (optional) | +-------------------------------+ +-------------------------------+ | Directionality (optional) | | Directionality (optional) | +-------------------------------+ +-------------------------------+ | Max Signaling Delay (optional)| | Max Signaling Delay (optional)| +-------------------------------+ +-------------------------------+ | Priority-Preemption (optional)| | Priority-Preemption (optional)| +-------------------------------+ +-------------------------------+ | Network Protection (optional) | | Network Protection (optional) | +-------------------------------+ +-------------------------------+ | Side Protection (optional) | | Side Protection (optional) | +-------------------------------+ +-------------------------------+ | Diversity (optional) | | Diversity (optional) | +-------------------------------+ +-------------------------------+ | Service-related (optional) | | Service-related (optional) | +-------------------------------+ +-------------------------------+ Figure 8: G.LSP Modify request Depending on the modification request the explicit route field can take different values. For instance, if the modification request only concerns the source-side protection, then the explicit route field remains empty. However, if the modification request implies to change the priority of the G.LSP along the whole path then the explicit route field is the same as the one calculated during the G.LSP create request by the CSPF algorithm. In this case, the explicit route field is defined by the G.LSP identifier since the intermediate ONEs keep track of the route established for the corresponding G.LSP. Note: there are some cases where the framing-bandwidth value of a G.LSP can not be changed. These exceptions are TBD. 1. Intra-Domain - G.LSP Modification Procedure The G.LSP Modification procedure and other related mechanism are TBD. Papadimitriou et al. Expires May 2001 36 draft-papadimitriou-onni-frame-01.txt November 2000 2. Inter-Domain - G.LSP Modification Procedure The G.LSP modification procedure should include the following steps: - Since the modify message may be sent over IrDI-NNI interfaces (meaning through separate administrative authority and thus between optical networks) some admission control should be provided at the boundary ONE to control the identity (by means of the Carrier ID) of the requestor The G.LSP Modification procedure and other related mechanism are TBD. 7.5.3.2 G.LSP modify response The G.LSP modify response is directed from the destination UNI-C to the source UNI-C through the following sequence: - UNI: Destination UNI-C -> UNI-N - NNI: Destination IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI - UNI: UNI-N -> Source UNI-C The following figure describes the G.LSP modify response message sent by the terminating UNI-C to the UNI-N and the corresponding message sent by the terminating IaDI-NNI after the treatment performed on this message: +-------------------------------+ +-------------------------------+ | G.LSP ID | | G.LSP ID | +-------------------------------+ +-------------------------------+ | Result Code | | Result Code | +-------------------------------+ +-------------------------------+ | Bandwidth-Framing (optional) | | Bandwidth-Framing (optional) | +-------------------------------+ +-------------------------------+ | SDH/SONET (optional) | | SDH/SONET (optional) | +-------------------------------+ +-------------------------------+ | Optical (optional) | | Optical (optional) | +-------------------------------+ +-------------------------------+ | Directionality (optional) | | Directionality (optional) | +-------------------------------+ +-------------------------------+ | Max Signaling Delay (optional)| | Max Signaling Delay (optional)| +-------------------------------+ +-------------------------------+ | Priority-Preemption (optional)| | Priority-Preemption (optional)| +-------------------------------+ +-------------------------------+ | Network Protection (optional) | | Network Protection (optional) | +-------------------------------+ +-------------------------------+ | Side Protection (optional) | | Side Protection (optional) | +-------------------------------+ +-------------------------------+ | Diversity (optional) | | Diversity (optional) | +-------------------------------+ +-------------------------------+ | Service-related (optional) | | Service-related (optional) | Papadimitriou et al. Expires May 2001 37 draft-papadimitriou-onni-frame-01.txt November 2000 +-------------------------------+ +-------------------------------+ Figure 9: G.LSP Modify response The G.LSP modify request could also be generated by an IaDI-NNI during the creation (or recovery) of a high-priority G.LSP requesting some of the resources used by the low-priority G.LSP. This case is analyzed is the next section of this proposal. 7.5.4 G.LSP Status The G.LSP status message includes the G.LSP status request and response message. 7.5.4.1 Initiating UNI-C When initiated by the UNI-C, the G.LSP status query process includes the G.LSP status request: - UNI: Source UNI-C -> UNI-N) - Optionally NNI: Source IaDI-NNI -> _ -> IaDI-NNI) - Optionally NNI: IaDI-NNI -> _ -> Destination IaDI-NNI) The G.LSP status response could be the following sequence of messages: - Optionally NNI: Destination IaDI-NNI -> _ -> IaDI-NNI) - Optionally NNI: IaDI-NNI -> _ -> Destination IaDI-NNI) - UNI: UNI-N -> Destination UNI-C) 7.5.4.2 Initiating UNI-N This case is not covered by the NNI Specification. 7.5.4.3 Initiating IaDI-NNI This case is considered to provide the ability for an IaDI-NNI interface to request about the status of an established G.LSP passing through the corresponding internal ONE. Two directions are possible, either to the source UNI-C: - NNI: G.LSP Status Request (IaDI-NNI -> _ -> Source IaDI-NNI) - UNI: G.LSP Status Request (UNI-N -> Source UNI-C) - UNI: G.LSP Status Response (Source UNI-C -> UNI-N) - NNI: G.LSP Status Response (Source IaDI-NNI -> _ -> IaDI-NNI) or to the destination UNI-C: - NNI: G.LSP Status Request (IaDI-NNI -> _ -> Destination IaDI-NNI) - UNI: G.LSP Status Request (UNI-N -> Destination UNI-C) - UNI: G.LSP Status Response (Destination UNI-C -> UNI-N) - NNI: G.LSP Status Response (Destination IaDI-NNI -> _ -> IaDI-NNI) Since the status request message may be sent over IrDI-NNI interfaces (meaning through separate administrative authority and Papadimitriou et al. Expires May 2001 38 draft-papadimitriou-onni-frame-01.txt November 2000 thus between optical networks) some CAC control should be provided at the boundary ONE to control the identity (by means of the Carrier ID) of the requestor. 4. Initiating IrDI-NNI This case is considered to provide the ability for an IrDI-NNI interface to request about the status of an established G.LSP passing through the corresponding boundary ONE. Two directions are possible, either to the source UNI-C: - NNI: G.LSP Status Request (IrDI-NNI -> _ -> Source IaDI-NNI) - UNI: G.LSP Status Request (UNI-N -> Source UNI-C) - UNI: G.LSP Status Response (Source UNI-C -> UNI-N) - NNI: G.LSP Status Response (Source IaDI-NNI -> _ -> IrDI-NNI) or to the destination UNI-C: - NNI: G.LSP Status Request (IrDI-NNI -> _ -> Destination IaDI-NNI) - UNI: G.LSP Status Request (UNI-N -> Destination UNI-C) - UNI: G.LSP Status Response (Destination UNI-C -> UNI-N) - NNI: G.LSP Status Response (Destination IaDI-NNI -> _ -> IrDI-NNI) 7.5.5 Notifications The IaDI-NNI interface may send a G.LSP notification message to notify the source and/or destination UNI-C about the current status of a G.LSP. This G.LSP notification message has to be considered has an unsolicited message. The notification messages could follow one of these sequences: - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI) - NNI: Intermediate IaDI-NNI -> _ -> Destination IaDI-NNI) - UNI: UNI-N -> Destination UNI-C - NNI: Intermediate IaDI-NNI -> _ -> Intermediate IaDI-NNI - NNI: Intermediate IaDI-NNI -> _ -> Source IaDI-NNI - UNI: UNI-N -> Source UNI-C 7.6 Constraint-based Routing The section describes the concepts of Explicit route and Record route. In order to introduce these concepts, we first describe the mechanisms to establish bi-directional G.LSPs. 7.6.1 Bi-directional G.LSP setup The assumption made throughout this proposal is that G.LSP are optical paths or TDM circuits whose setup is bi-directional (even if we consider that a bi-directional path results from the merge of two unidirectional paths). However, G.LSPs are fundamentally unidirectional and point-to-point logical-link connections. Papadimitriou et al. Expires May 2001 39 draft-papadimitriou-onni-frame-01.txt November 2000 A simple solution can be proposed to avoid racing condition for bi- directional G.LSP setup. As proposed by [CRLDP-OPT], the solution suggests forming a master and slave relationship between two adjacent ONEs. The ONE with the higher ONE Ipv4 address is the master to the other. It is always the master ONE that makes logical- port assignment for both itself and its slave peer. Since the ONE Ipv4 address is a static information, we propose to enhance this mechanism, and use the previous mechanism as the initial step. After, when a G.LSP is created for another user-group the priority is given to the slave of the previous step. Hence, the master-slave relationship is defined per user-group. 7.6.2 Explicit Route In the distributed model, the explicit route is calculated through the CSPF algorithm at the source of the G.LSP within the optical network. The source ONE can be a boundary ONE, an area border ONE or an autonomous-system boundary ONE. In the last two cases the source ONE is referred as a source intermediate ONE. In the centralized model, the explicit route is calculated through the CSPF algorithm at the Network Management System. In this case, the NMS informs the G.LSP source ONE about the nodes to include in the path that it will request through the optical network. The value of the explicit route is a variable-size list including three types of fields: - Internal-point ID - Node ID (i.e. the Ipv4 address of the ONE) - Autonomous System ID which is the identifier of a set of ONEs having a single routing policy running under a single administrative authority. Note: Internal-point ID is considered here as a `heuristic' to avoid to specify the mechanism through which the input and output logical- port ID of the G.LSP `link' are determined between neighboring ONE during the G.LSP setup process. These values are case specific: - The internal-point ID is the sub-field used to identify the next- hop ONE during the G.LSP setup process - The node ID is the sub-field used to identify a subsequent hop within the same area or same autonomous-system (within the same IGP technical administration domain) - The autonomous-system ID (which corresponds to the autonomous- system number) is the sub-field used to identify a subsequent hierarchical level included within the explicit route calculated for the G.LSP. Example 1: Papadimitriou et al. Expires May 2001 40 draft-papadimitriou-onni-frame-01.txt November 2000 If the explicit route corresponds to the following hop sequence: Source ONE [0] > Internal ONE [1] > Internal ONE [2] > Internal ONE [i] > _ > Internal ONE [N-1] > Destination ONE [N] represented by the following sequence of identifiers which corresponds to explicit route at the initial source point: Source Termination-Point ID [0] > Internal-point ID [1] > Node ID [2] > _ > Node ID [i] > _ > Node ID [N-1] > Destination Termination- point [N] 1. Then, at the first hop, the explicit route is the following: Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N] 2. At the second hop, the explicit route is the following: Internal-point ID [2] > Internal-point ID [3] > _ > Node ID [i] > _ > Node ID [N-1] _ Destination Termination-point [N] 3. At the hop i, the explicit route is the following: Internal-point ID [i] > Internal-point ID [I+1] > _ > Node ID [N-1] > Destination Termination-point [N] 4. At the last hop, the explicit route is the following: Destination Termination-point [N] Example 2: If the explicit route corresponds to the following hop sequence: Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ > Internal ONE [i] > _ > Internal ONE [N-1] > Destination ONE [N] represented by the following sequence of identifiers which corresponds to explicit route at the initial source point: Source Termination-Point ID [0] > Internal-point ID [1] > Node ID [2] _ > Node ID [i] > _ > Node ID [I+M] > Destination Termination- point [N] where the Node ID [I+M] corresponds to an area border ONE (I + M < N) 1. Then, at the first hop, the explicit route is the following: Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _ > Node ID [I+M] > Destination Termination-point [N] Papadimitriou et al. Expires May 2001 41 draft-papadimitriou-onni-frame-01.txt November 2000 2. At the second hop, the explicit route is the following: Internal-point ID [2] > Internal-point ID [3] > _ > Node ID [i] > _ > Node ID [I+M] > Destination Termination-point [N] 3. At the hop i, the explicit route is the following: Internal-point ID [i] > Internal-point ID [I+1] > _ > Node ID [I+M] > Destination Termination-point [N] 4. At the hop I+M, the explicit route is the following: Internal-point ID [I+M] > Internal-point ID [I+M+1] > _ > Node ID [N-1] > Destination Termination-point ID [N] Where the Internal-point ID [I+M] is the internal-point of the ONE located at the border of the area and directed to the outgoing area and the Internal-point ID [I+M+1] is the internal-point of the internal ONE located within the incoming area. So the area border ONE calculate the explicit route to the destination termination-point ID by executing the C-SPF algorithm and inserts a number of hops within the explicit route field in order to reach the destination termination-point ID of the requested G.LSP. Example 3: If the explicit route corresponds to the following hop sequence: Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ > Internal ONE [i] > _ > Autonomous-System [N-1] > Destination ONE [N] represented by the following sequence of identifiers which corresponds to explicit route at the initial source point: Source Termination-Point ID [0] > Internal-point ID [1] > Node ID [2] > _ > Node ID [i] > _ > AS ID [N-1] > Destination Termination- point [N] Then, at the first hop, the explicit route is the following: Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _ > AS ID [N-1] > Destination Termination-point [N] At the hop i, the explicit route is the following: Internal-point ID [i] > Internal-point ID [I+1] > _ > AS ID [N-1] > Destination Termination-point [N] At the hop N-2, the explicit route is the following: Papadimitriou et al. Expires May 2001 42 draft-papadimitriou-onni-frame-01.txt November 2000 Internal-point ID [N-2] > Internal-point ID [N-1] > Destination Termination-point ID [N] Where the Internal-point ID [N-2] is the internal-point of the ONE located at the boundary of the outgoing AS and the Internal-point ID [N-1] is the internal-point of the ONE located at the boundary of the incoming AS. So the outgoing boundary ONE selects the internal-point of the next hop and replaces the AS ID by the corresponding internal-point ID. Now the boundary ONE of the incoming AS has to calculate the explicit route to the destination termination-point ID by executing the CSPF algorithm. Consequently a number of hops are inserted within the explicit route field in order to reach the destination termination-point ID of the requested G.LSP. 7.6.3 Record route In order to improve the reliability and the manageability of the G.LSP being established we optionally introduce the concept of the route-record of lightpath of the G.LSP being established. The record-route is an empty field at the source ONE and to capture the precise route of the path being set up with port level information. This is done by the following procedure: at each intermediate ONE, the NNI inserts its node ID and both the output logical-port ID and the input logical-port ID selected for the path in the G.LSP create request message. The ligthpath create request message received by the destination ONE and the G.LSP create response message received by the source ONE will have the complete route followed by the established G.LSP at the logical-port ID level. Example 1: If the explicit route corresponds to the following hop sequence: Source ONE [0] > Internal ONE [1] > Internal ONE [2] > _ > Internal ONE [i] > _ > Internal ONE [N-1] > Destination ONE [N] represented by the following sequence of identifiers which corresponds to explicit route at the initial source point: Explicit Route = Source Termination-Point ID [0] > Internal-point ID [1] _ Node ID [2] > _ > Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N] Record Route = Source Termination-Point ID [0] Papadimitriou et al. Expires May 2001 43 draft-papadimitriou-onni-frame-01.txt November 2000 1. Then, at the first hop, the explicit and record routes are the following: Explicit Route = Internal-point ID [1] > Internal-point ID [2] > _ > Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N] Record Route = Source Termination-Point ID [0] > Internal-point ID [1] 2. At the second hop, the explicit and record routes are the following: Explicit Route = Internal-point ID [2] > Internal-point ID [3] > _ > Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N] Record Route = Source Termination-Point ID [0] > Internal-point ID [1] > Internal-point ID [2] 3. At the hop i, the explicit are record routes are the following: Explicit Route = Internal-point ID [i] > Internal-point ID [I+1] > _ > Node ID [N-1] > Destination Termination-point [N] Record Route = Source Termination-Point ID [0] > Internal-point ID [1] > Internal-point ID [2] > _ > Internal-point ID [i] 4. At the last hop, the explicit and record routes are the following: Explicit Route = Destination Termination-point [N] Record Route = Source Termination-Point ID [0] > Internal-point ID [1] _ Node ID [2] > _ > Node ID [i] > _ > Node ID [N-1] > Destination Termination-point [N] In the transmit direction the internal-point ID are the input internal-point ids. In the reverse direction, the record-route included within the G.LSP create response message each intermediate ONE inserts the input internal-point id which corresponds to the output internal-point id of the transmit direction. 7.7 Extended NNI Signaling Services The extended NNI signaling services include the following processes: - Resource Reservation mechanisms - Protection mechanisms - Preemption mechanisms These mechanisms are related to the priority level and value associated to the G.LSPs. The priority value is included within the client G.LSP create request. Papadimitriou et al. Expires May 2001 44 draft-papadimitriou-onni-frame-01.txt November 2000 7.7.1 Framing-Bandwidth - Priority The G.LSP create request message includes the desired framing and bandwidth requested by the client. Each of the source, intermediate and destination ONE included within the explicit route field has a local ONE database including for each of its logical-ports: - the available bandwidth (AB) - the minimum and maximum reservable bandwidth (MinRB and MaxRB) - the associated priority (AB[p], MinRB[p] and MaxRB[p]) The priority value is the lowest priority at which this bandwidth is available. So, the logical-point resource information is represented by the following entries into the local ONE database: Local ONE Neighbor ONE 1 State -------------------------------------------------------------------- LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active Local ONE Neighbor ONE 2 State -------------------------------------------------------------------- LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active LP-ID AB[p] MinRB[p] MaxRB[p] LP-ID AB[q] MinRB[q] MaxRB[q] Active When the source ONE receives a G.LSP create request, and the CSPF has established the corresponding path (i.e., explicit route) into the optical sub-network, the following sequence occurs: - the source ONE waits until receiving the G.LSP create response message to update the local database (and subsequently flood the ONE updates throughout the optical sub-network) - the source ONE marks the `planned' reserved bandwidth as reserved so that no other G.LSP create request can use it. Consequently, we define four states for the framing-bandwidth parameter within the local ONE database: - Unused: FB not in use, can be reserved to establish a G.LSP - Reserved: the corresponding ONE is wanting for a G.LSP create request before marking the corresponding value as used - Used: FB in use, the only way to use this resource is through the preemption mechanism see below - Reservable: the corresponding ONE is waiting for the G.LSP delete response before marking the corresponding value as unused State Diagram: State Diagram is TDB For instance, if the G.LSP is requested with 1 units of bandwidth and with priority r then the local database is updated as follows after the G.LSP create request message has been forwarded to the next hop: Papadimitriou et al. Expires May 2001 45 draft-papadimitriou-onni-frame-01.txt November 2000 Local ONE Status G.LSP -------------------------------------------------------------------- LP-ID Reserved Bandwidth [p] Used G.LSP ID 1 LP-ID Available Bandwidth [q] Unused G.LSP ID 2 LP-ID Reserved Bandwidth [r] Reserved G.LSP ID 3 LP-ID Reserved Bandwidth [s] Used G.LSP ID 4 After the G.LSP create response message has been forwarded to the next hop, the local database is updated as follows: Local ONE Status G.LSP -------------------------------------------------------------------- LP-ID Reserved Bandwidth [p] Used G.LSP ID 1 LP-ID Available Bandwidth [q] Unused G.LSP ID 2 LP-ID Reserved Bandwidth [r] Used G.LSP ID 3 LP-ID Reserved Bandwidth [s] Used G.LSP ID 4 7.7.2 Protection - Priority Mechanisms TBD. 7.7.3 Preemption mechanisms The preemption mechanisms are related to the pre-emptability of the G.LSP during G.LSP creation process (setup preemption) or during the application of the G.LSP protection (recovery preemption). The applicability of the proposed mechanism is still under study. 1. Setup Preemption If the G.LSP create requests with 1 unit of bandwidth and with priority p (p > q > r > s > t) and there is no more available bandwidth as indicated within the local ONE database: Local ONE Status G.LSP -------------------------------------------------------------------- LP-ID Reserved Bandwidth [q] Used G.LSP ID 1 LP-ID Reserved Bandwidth [r] Used G.LSP ID 2 LP-ID Reserved Bandwidth [s] Used G.LSP ID 3 LP-ID Reserved Bandwidth [t] Used G.LSP ID 4 Then the reserved bandwidth for G.LSP 4 is preempted and marked as reserved for this new G.LSP request; the local database is updated as follows after the G.LSP create request message has been forwarded to the next hop: Local ONE Status G.LSP -------------------------------------------------------------------- LP-ID Reserved Bandwidth [q] Used G.LSP ID 1 LP-ID Reserved Bandwidth [r] Used G.LSP ID 2 LP-ID Reserved Bandwidth [s] Used G.LSP ID 3 Papadimitriou et al. Expires May 2001 46 draft-papadimitriou-onni-frame-01.txt November 2000 LP-ID Reserved Bandwidth [p] Reserved G.LSP ID 5 After the G.LSP create response message has been forwarded to the next hop, the local database is updated as follows: Local ONE Status G.LSP -------------------------------------------------------------------- LP-ID Reserved Bandwidth [q] Used G.LSP ID 1 LP-ID Reserved Bandwidth [r] Used G.LSP ID 2 LP-ID Reserved Bandwidth [s] Used G.LSP ID 3 LP-ID Reserved Bandwidth [p] Used G.LSP ID 5 The lower priority G.LSP preemption generates as notification message to the corresponding source ONE and destination ONE which in turn forward a notification message to the corresponding source and destination clients. State Diagram: State Diagram is TDB 2. Recovery Preemption The same procedure and mechanisms as described in the previous subsection are applicable but in this case the preemption decision is related to unavailable bandwidth during G.LSP recovery. In this case, G.LSP of higher holding priority will take the precedence over G.LSP of lower priority. This recovery preemption mechanism is applied link-by-link and consequently can be applied from the source ONE to the destination ONE. This means that since the holding priority of a given ligthpath is the same on each the intermediate through which this G.LSP has been established the only way to not recover a higher priority G.LSP could only be related to a local decision. However, for an optical network, which does not oversubscribe the number of established high-priority G.LSP this situation should not occur. State Diagram: State Diagram is TDB 8. Hierarchical Network Model The hierarchical routing model considered here is based on the OSPF- Like protocol version whose requirements have been detailed in the previous sections of this document and the eBGP protocol. Extensions of the eBGP protocol are TBD. The first model considers the optical sub-network as corresponding to an OSPF area (distinction is made on the NNI interface type): - The IrDI-NNI interfaces are defined as Trusted NNI interfaces and they are running OSPF. In this case, IrDI-NNI interface is the interface between the backbone area0 and the areas surrounding the area0 Papadimitriou et al. Expires May 2001 47 draft-papadimitriou-onni-frame-01.txt November 2000 - The IaDI-NNI interfaces are defined as Trusted NNI interfaces and they are running OSPF. In this case, the IaDI-NNI interface is considered as the interface between internal ONE or between an internal and a boundary ONE belonging to the same area. The second model considers the optical sub-network as corresponding to an OSPF Autonomous System (distinction is made on the NNI interface type and on the NNI interface privacy): - The IaDI-NNI interfaces are defined as Trusted NNI interfaces and they are running OSPF. In this case, the IaDI-NNI interface is considered as the interface between internal ONE or between an internal and a boundary ONE belonging to the same Autonomous System. - The IrDI-NNI interfaces are defined as Untrusted NNI interfaces and they are running eBGP. In this case, the IrDI-NNI interface is considered as the interface between the OSPF Autonomous System and the external network. The corresponding ONE can be defined as an Autonomous System optical entity. The proposed model can be combined to form a hierarchical optical network: By combining both models, we obtain the following model: - The IaDI-NNI interfaces are defined as Trusted NNI interfaces running OSPF protocol - The IaDI-NNI or IrDI-NNI interfaces are defined as Trusted NNI interfaces running OSPF protocol - The IrDI-NNI interfaces are defined as Untrusted NNI interfaces running eBGP protocol The eBGP protocol is running on sub-network boundary ONEs (which from the OSPF point-of-view can be considered as an ASBR). The model provides the capacity to connect several OSPF Autonomous Systems together through eBGP protocol. The hierarchical optical network model is represented by the following figure: +------------------------------------------------------------------+ | OSPF Autonomous System 10 | | +-------------+ | | |Boundary ONE1| IaDI-NNI | | |OSPF Area 10 |-- | | +-------------+ | +-------------+ IaDI-NNI +-------------+ | | ------|Internal ONE4|----------|Internal ONE6| | | +-------------+ ------|OSPF Area 0 |----------|OSPF Area 30 | | | |Boundary ONE2| | +-------------+ +-------------+ | | |OSPF Area 10 |-- |IaDI-NNI | | +-------------+ IaDI-NNI | | | | | | | | | |IaDI-NNI | | +-------------+ +-------------+ IaDI-NNI +-------------+ | | |Boundary ONE3|---------|Internal ONE5|----------|Internal ONE7| | Papadimitriou et al. Expires May 2001 48 draft-papadimitriou-onni-frame-01.txt November 2000 | |OSPF Area 20 |---------|OSPF Area 0 |----------|OSPF Area 40 | | | +-------------+IaDI-NNI +-------------+ +-------------+ | | IrDI- | |IrDI- | | NNI | |NN | +--------|------------------------------------------------|--------+ | | | | +--------|------------------------------------------------|--------+ | IrDI- | BGP Transit |IrDI- | | NNI | Area |NN | | +-------------+ +-------------+ +-------------+ | | |Boundary ONE1|---------|Internal ONE2|----------|Boundary ONE3| | | |OSPF Area 0 |---------|OSPF Area 0 |----------|OSPF Area 0 | | | +-------------+IaDI-NNI +-------------+ IaDI-NNI +-------------+ | | | | | | | +-------------+ +-------------+ +-------------+ | | |Boundary ONE3|---------|Internal ONE5|----------|Boundary ONE7| | | |OSPF Area 0 |---------|OSPF Area 0 |----------|OSPF Area 0 | | | +-------------+IaDI-NNI +-------------+ IaDI-NNI +-------------+ | | IrDI- | |IrDI- | | NNI | |NN | +--------|------------------------------------------------|--------+ | | | | +--------|----------+ +----------|--------+ | IrDI- | | | |IrDI- | | NNI | | | |NN | | +-------------+ | | +-------------+ | | |Boundary ONE1| | | |Boundary ONE1| | | |OSPF Area 10 | | | |OSPF Area 10 | | | +-------------+ | | +-------------+ | | | | | | | | +-------------+ | | +-------------+ | | |Boundary ONE2| | | |Boundary ONE2| | | |OSPF Area 10 | | | |OSPF Area 10 | | | +-------------+ | | +-------------+ | | BGP AS-10 | | BGP AS-20 | +-------------------+ +-------------------+ Figure 10: Hierarchical optical network model - IaDI-NNI interfaces are running OSPF-Lite protocol (note IaDI-NNI interfaces could be untrusted or trusted, however, in most cases IaDI-NNI interfaces are defined as trusted NNI interfaces) - IrDI-NNI Untrusted interfaces are running eBGP extended protocol Since the OSPF version considered in this section refers to OSPF- Lite whose requirements have been detailed in the section 6, some extensions need to be considered in order to: - generate ONE advertisements at Autonomous System boundary ONEs (these ONE advertisements are internal summary advertisements) Papadimitriou et al. Expires May 2001 49 draft-papadimitriou-onni-frame-01.txt November 2000 - generate ONE advertisements at Area boundary ONEs (these ONE advertisements are external summary advertisements) 9. Security Considerations Security considerations have been briefly described within the Section 4 where we describe the security of the signaling control plane. Other security considerations are for further study. 10. References 1. [CRLDP-OPT] B. Tang et al., `Extensions to CR-LDP for Path Establishment in Optical Networks', Internet Draft, draft-tang- crldp-optical-00.txt, September 2000. 2. [ENH-LSPS] D.Papadimitriou et al., `Enhanced LSP Services', Internet Draft, draft-papadimitriou-enhanced-lsps-01.txt, November 2000. 3. [GMPLS] P. Ashwood-Smith et al., `Generalized MPLS: Signaling Functional Description', Internet Draft, draft-ietf-mpls- generalized-signaling-00.txt, October 2000. 4. [MPLS-LMP] J. Lang et al., `Link Management Protocol', Internet Draft, draft-lang-mpls-lmp-01.txt, January 2001. 5. [MPLS-OUNI] B. Rajagopalan et al., `Signaling Requirements at the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni- signaling-00.txt, July 2000. 6. [MPLS-TE] S.Venkatachalam et al., `A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering', Internet Draft, draft-venkatachalam-interarea-mpls-te-01.txt, October 2000. 7. [OIF2000.125.2] B. Rajagopalan et al., `User Network Interface v1.0 Proposal', OIF Contribution 125.2, October 2000. 8. [OIF2000.200] D. Pendarakis et al., `Signaling Transport Mechanisms for UNI 1.0', OIF Contribution 200, September 2000. 9. [OIF2000.261.1] D. Papadimitriou et al., `Address Registration and Resolution', OIF Contribution 261, November 2000. 10. [RFC 1662] W. Simpson et al., `PPP in HDLC-like Framing', Internet RFC 1662, July 1994. 11. [RFC 2615] A. Malis et al., `PPP over SONET/SDH', Internet RFC 2615, June 1999. 11. Acknowledgments Papadimitriou et al. Expires May 2001 50 draft-papadimitriou-onni-frame-01.txt November 2000 The authors would like to thank Bernard Sales, Emmanuel Desmet, Hans De Neve, Fabrice Poppe and Jim Jones for their constructive comments. 12. Author's Addresses Dimitri Papadimitriou Alcatel NSG-NA F. Wellesplein 3, B-2018 Antwerpen, Belgium Phone: 32 3 2408491 Email: dimitri.papadimitriou@alcatel.be Michele Fontana Alcatel TND Via Trento 30, I-20059 Vimercate, Italy Phone: 39 039 6867053 Email: Michele.Fontana@netit.alcatel.it Gert Grammel Alcatel Optics Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-4453 Email: Gert.Grammel@netit.alcatel.it Yangguang Xu Lucent Technologies, Inc. 21-2A41, 1600 Osgood Street, North Andover, MA 01845 Phone: 1 978 4572345 Email: xuyg@lucent.com Zhi-Wei Lin Lucent Technologies, Inc. 101 Crawfords Corner Rd, Rm 3C-512, NJ 07733-3030 Phone: 1 732 9495141 Email: zwlin@lucent.com Sivakumar Sankaranarayanan Lucent Technologies, Inc. 101 Crawfords Corner Rd, Rm 3C-512, NJ 07733-3030 Phone: 1 732 9495578 Email: ssnarayanan@lucent.com Papadimitriou et al. Expires May 2001 51 draft-papadimitriou-onni-frame-01.txt November 2000 Raj Jain Nayna Networks 157 Topaz St., Milpitas, CA 95035, USA Phone: 408-956-8000X309 Email: raj@nayna.com Yang Cao Sycamore Networks 150 Apollo Drive, Chelmsford, MA 01824 Phone: 1 978-367-2518 Email: Yang.Cao@sycamorenet.com Yong Xue UUNET/WorlCom 22001 Loudoun County Parkway, Ashburn, VA 20148 Phone: 1 703 8865358 Email: yxue@uu.net Papadimitriou et al. Expires May 2001 52 draft-papadimitriou-onni-frame-01.txt November 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 Papadimitriou et al. Expires May 2001 53