One document matched: draft-papadimitriou-onni-frame-00.txt
Network Working Group D.Papadimitriou
Internet Draft M.Fontana
Document: draft-papadimitriou-onni-frame-00.txt G.Grammel
Expiration Date: May 2001 Alcatel
Yong Xue
UUNet
Yang Cao
Sycamore
Raj Jain
Nayna Networks
Yanguang Xu
Zhi-Wei Lin
S.Sankaranarayanan
Lucent
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.
The main objective is to propose a common approach for most of the
Papadimitriou et al. Expires May 2001 1
draft-papadimitriou-onni-frame-00.txt November 2000
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
7.5.1 G.LSP Creation......................................30
Papadimitriou et al. Expires May 2001 2
draft-papadimitriou-onni-frame-00.txt November 2000
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
related discovery processes. The section 7 is entirely dedicated to
Papadimitriou et al. Expires May 2001 3
draft-papadimitriou-onni-frame-00.txt November 2000
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
considered as bi-directional (and in a first phase as symmetric). A
Papadimitriou et al. Expires May 2001 4
draft-papadimitriou-onni-frame-00.txt November 2000
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-00.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 [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-00.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-00.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-00.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-00.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-00.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-00.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-00.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-00.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-00.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-00.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-00.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-00.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-00.txt November 2000
for the addressing of the client CNE termination-point identifiers
[OIF2000.261].
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-00.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)
[OIF-2000.267].
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 lightpaths 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-00.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 lightpaths he has
already established) the client CNE can only reference a G.LSP M to
which the new G.LSP N should be divergent. 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 ligthpath 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, area-local and AS-
wide ONE advertisements; a flooding rule is associated to each of
these ONE advertisements:
- Link-local ONE advertisements: flooding scope limited to adjacent
ONEs
- Area-local ONE advertisements: flooding scope limited to a local
area
- AS-wide ONE advertisements: flooding scope covers a whole
autonomous-system
Papadimitriou et al. Expires May 2001 21
draft-papadimitriou-onni-frame-00.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
Papadimitriou et al. Expires May 2001 22
draft-papadimitriou-onni-frame-00.txt November 2000
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.
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:
Papadimitriou et al. Expires May 2001 23
draft-papadimitriou-onni-frame-00.txt November 2000
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] 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
Papadimitriou et al. Expires May 2001 24
draft-papadimitriou-onni-frame-00.txt November 2000
To avoid an exponential increase of the ONE advertisements through
the optical network, the following flooding rules are applied:
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 area-local advertisements
For each of the ONE's adjacency, one area-local ONE advertisement is
generated and flooded within the corresponding area. The information
included in this ONE advertisement is summarized as follows: within
an area-local 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 area-local advertisement also includes the CNE
termination-point ID (and logical address to CNE termination-point
ID mapping) and the associated status.
3. Flooding AS-wide advertisements
For each area one AS-wide ONE advertisement is generated and flooded
within the corresponding autonomous-system. The information included
in this ONE advertisement is summarized as follows: within the AS-
wide 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])
Papadimitriou et al. Expires May 2001 25
draft-papadimitriou-onni-frame-00.txt November 2000
- Min Reservable Bandwidth: MinRB[p]
- Associated Link Protection level: Protection[p]
- Preemption types supported: Setup and/or Recovery
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), area-local
(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 area-local scope. ONE advertisements with a
area-local scope are not flooded beyond the area where they are
originated.
- The type-3 denotes that the LSA is flooded throughout the
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
Papadimitriou et al. Expires May 2001 26
draft-papadimitriou-onni-frame-00.txt November 2000
piggybacking could be included in the proposed version of the TrDP
Protocol.
- 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.1], 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:
Papadimitriou et al. Expires May 2001 27
draft-papadimitriou-onni-frame-00.txt November 2000
- Between the NNI interfaces, the signaling protocol must be IP-
based, the NNI IPv4 address is the one uniquely associated to the
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-00.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)
_
Papadimitriou et al. Expires May 2001 29
draft-papadimitriou-onni-frame-00.txt November 2000
Destination IrDI-NNI (sub-network j) = Intermediate IaDI-NNI (sub-
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 Logical Address | | Explicit Route |
+-----------------------------+ +---------------------------------+
| CNE Destination | | Record Route (optional) |
| Logical Address | | |
+-----------------------------+ +---------------------------------+
| Source User Group ID | | Source User Group ID |
Papadimitriou et al. Expires May 2001 30
draft-papadimitriou-onni-frame-00.txt November 2000
+-----------------------------+ +---------------------------------+
| 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** (opt.)| | Max Signaling Delay** (optional)|
+-----------------------------+ +---------------------------------+
| Priority-Preemption | | Priority-Preemption (optional) |
| (optional) | | |
+-----------------------------+ +---------------------------------+
| Network Protection | | Network Protection (optional) |
| (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 lightpaths 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
Papadimitriou et al. Expires May 2001 31
draft-papadimitriou-onni-frame-00.txt November 2000
- Destination User Group ID
- 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 logical addresses 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 logical address 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 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
Papadimitriou et al. Expires May 2001 32
draft-papadimitriou-onni-frame-00.txt November 2000
boundary ONE to control the identity (by means of the Carrier ID) of
the requestor
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 Logical Address | | ONE Destination |
| | | Termination-point ID |
+-----------------------------+ +---------------------------------+
| CNE Destination | | Record Route* |
| Logical Address | | |
+-----------------------------+ +---------------------------------+
| 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
Papadimitriou et al. Expires May 2001 33
draft-papadimitriou-onni-frame-00.txt November 2000
The G.LSP delete 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: 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.
+---------------------------------+
| ONE Source Termination-point ID |
+-----------------------------+ +---------------------------------+
| CNE Source Logical Address | | ONE Destination |
| | | Termination-point ID |
+-----------------------------+ +---------------------------------+
| CNE Destination | | Explicit Route* |
| Logical Address | | |
+-----------------------------+ +---------------------------------+
| Contract ID (optional) | | Carrier ID (optional) |
+-----------------------------+ +---------------------------------+
| G.LSP ID | | G.LSP ID |
+-----------------------------+ +---------------------------------+
| Result Code | | 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-00.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 Logical Address* | | ONE Source Termination-point ID |
+-----------------------------+ +---------------------------------+
| CNE Destination | | ONE Destination |
| Logical Address | | 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-00.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 (optional) |
+-----------------------------+ +---------------------------------+
| Optical (optional) | | Optical (optional) |
+-----------------------------+ +---------------------------------+
| Directionality (optional) | | Directionality (optional) |
+-----------------------------+ +---------------------------------+
| Max Signaling Delay** | | Max Signaling Delay** |
| (optional) | | (optional) |
+-----------------------------+ +---------------------------------+
| Priority-Preemption | | Priority-Preemption |
| (optional) | | (optional) |
+-----------------------------+ +---------------------------------+
| Network Protection | | Network Protection |
| (optional) | | (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 route field takes
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
Papadimitriou et al. Expires May 2001 36
draft-papadimitriou-onni-frame-00.txt November 2000
The G.LSP Modification procedure and other related mechanism are
TBD.
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 | | Max Signaling Delay |
| (optional) | | (optional) |
+------------------------------+ +--------------------------------+
| Priority-Preemption | | Priority-Preemption |
| (optional) | | (optional) |
+------------------------------+ +--------------------------------+
| Network Protection (optional)| | Network Protection (optional) |
+------------------------------+ +--------------------------------+
Papadimitriou et al. Expires May 2001 37
draft-papadimitriou-onni-frame-00.txt November 2000
| Side Protection (optional) | | Side Protection (optional) |
+------------------------------+ +--------------------------------+
| Diversity (optional) | | Diversity (optional) |
+------------------------------+ +--------------------------------+
| Service-related (optional) | | Service-related (optional) |
+------------------------------+ +--------------------------------+
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)
Papadimitriou et al. Expires May 2001 38
draft-papadimitriou-onni-frame-00.txt November 2000
- 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
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
Papadimitriou et al. Expires May 2001 39
draft-papadimitriou-onni-frame-00.txt November 2000
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.
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)
Papadimitriou et al. Expires May 2001 40
draft-papadimitriou-onni-frame-00.txt November 2000
- 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:
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]
Papadimitriou et al. Expires May 2001 41
draft-papadimitriou-onni-frame-00.txt November 2000
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]
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]
Papadimitriou et al. Expires May 2001 42
draft-papadimitriou-onni-frame-00.txt November 2000
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:
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:
Papadimitriou et al. Expires May 2001 43
draft-papadimitriou-onni-frame-00.txt November 2000
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]
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
Papadimitriou et al. Expires May 2001 44
draft-papadimitriou-onni-frame-00.txt November 2000
- Protection mechanisms
- Preemption mechanisms
These mechanisms are related to the priority level and value
associated to the lightpaths. The priority value is included within
the client G.LSP create request.
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
Papadimitriou et al. Expires May 2001 45
draft-papadimitriou-onni-frame-00.txt November 2000
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:
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
Papadimitriou et al. Expires May 2001 46
draft-papadimitriou-onni-frame-00.txt November 2000
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
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
Papadimitriou et al. Expires May 2001 47
draft-papadimitriou-onni-frame-00.txt November 2000
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
- 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| |
Papadimitriou et al. Expires May 2001 48
draft-papadimitriou-onni-frame-00.txt November 2000
| +-------------+ ------|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| |
| |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
Papadimitriou et al. Expires May 2001 49
draft-papadimitriou-onni-frame-00.txt November 2000
- 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)
- 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. [GMPLS] P. Ashwood-Smith et al., `Generalized MPLS: Signaling
Functional Description', Internet Draft, draft-ietf-mpls-
generalized-signaling-00.txt, October 2000.
3. [MPLS-LMP] J. Lang et al., `Link Management Protocol', Internet
Draft, draft-lang-mpls-lmp-01.txt, January 2001.
4. [MPLS-OUNI] B. Rajagopalan et al., `Signaling Requirements at
the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni-
signaling-00.txt, July 2000.
5. [OIF2000.125.2] B. Rajagopalan et al., `User Network Interface
v1.0 Proposal', OIF Contribution 125.2, October 2000.
6. [OIF2000.200] D. Pendarakis et al., `Signaling Transport
Mechanisms for UNI 1.0', OIF Contribution 200, September 2000.
7. [OIF2000.261] D. Papadimitriou et al., `Address Registration and
Resolution', OIF Contribution 261, November 2000
8. [OIF2000.267] D. Papadimitriou et al., `Lightpath Parameters',
OIF Contribution 267, November 2000.
9. [RFC 1662] W. Simpson et al., `PPP in HDLC-like Framing',
Internet
RFC 1662, July 1994.
Papadimitriou et al. Expires May 2001 50
draft-papadimitriou-onni-frame-00.txt November 2000
10. [RFC 2615] A. Malis et al., `PPP over SONET/SDH', Internet RFC
2615, June 1999.
11. Acknowledgments
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
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
Raj Jain
Nayna Networks
157 Topaz St., Milpitas, CA 95035, USA
Phone: 408-956-8000X309
Email: raj@nayna.com
Yangguang Xu
Lucent Technologies, Inc.
21-2A41, 1600 Osgood Street, North Andover, MA 01845
Papadimitriou et al. Expires May 2001 51
draft-papadimitriou-onni-frame-00.txt November 2000
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 52
draft-papadimitriou-onni-frame-00.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
| PAFTECH AB 2003-2026 | 2026-04-24 01:03:41 |