Internet DRAFT - draft-hahm-optical-restoration
draft-hahm-optical-restoration
Network Working Group Jin Ho Hahm
Internet-Draft ETRI
Kwang-il Lee
Expiration Date: June 2001 NIST
December 2000
Bandwidth Provisioning and Restoration Mechanisms in Optical Networks
<draft-hahm-optical-restoration-01.txt>
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/lid-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
With the advent of tunable lasers and optical switches, dynamic
configuration of optical networks has become possible. This
Internet-Draft presents a signaling mechanism for bandwidth
provisioning and restoration based on this dynamic configuration of
optical networks. The mechanisms proposed use a 1:N restoration
scheme, preparing backup lightpaths in advance, before failures
occur.
Hahm et al [Page 1]
draft-hahm-optical-restoration-01.txt December 2000
1. Introduction
In general, Internet backbone networks are overbuilt in comparison to
average traffic volumes, in order to support fluctuations in traffic
levels and to stay ahead of traffic growth rates. Therefore, any
given time there are typically under utilized capacity in deployed
network facilities.
One of the most important concepts in network management is
maintaining the survivability of networks. When there are link
failures or the like, any affected routes should be repaired as soon
as possible. Today's SONET networks can achieve recovery times of
50msec, but depend on 1+1 backup network resources to do so. If
instead an adaptive 1:N restoration mechanism can be applied, network
survivability can still be enhanced while minimizing the waste in
network resources.
This Internet Draft proposes a mechanism for bandwidth provisioning
and restoration processes which meet this goal, and defines the
associated signaling and message types.
2. Basic concept for bandwidth provisioning and restoration
This section describes the basic concept of bandwidth provisioning
and restoration mechanisms in optical networks.
o OXC system architecture
The OXC system architecture for lambda switching has been introduced
in the Internet-Draft[1]. Our proposed bandwidth provisioning and
restoration mechanisms are based on this architecture.
The internal processing in OXC system for lambda switching is briefly
outlined here. This is presented only as an aid to understanding,
because other basic mechanisms would also suffice.
An Optical Crossconnect (OXC) has several incoming and outgoing
lambda ports, connected to adjacent OXCs, and several incoming and
outgoing data ports attached to a controlling router. An OXC has an
OXC Switching Controller (OSC) and OXC switch fabric.
The OSC converts the received messages (mentioned in section 5) to
the proper control command, and sends this command to the OXC fabric.
The commands to control the OXC fabric are as follows: connect (and
disconnect) between an incoming lambda port and outgoing lambda port;
connect (and disconnect) between an incoming lambda port and outgoing
data port; connect (and disconnect) between an incoming data port and
an outgoing lambda port.
Hahm et al [Page 2]
draft-hahm-optical-restoration-01.txt December 2000
Based on these commands, a chain of connections through OXCs can form
an end-to-end lightpath. The OXC starting a lightpath is called the
ingress OXC, and the OXC ending a lightpath is called the egress OXC.
The OXCs inside the lightpath are called the intermediate OXCs.
An OXC fabric receives commands from the OSC, and replies whether the
command was successful or not. The OSC then converts the result into
the form of a message (described in section 5) to send to the counter
OSC through the network.
+---------+
| | +-----------------------+
| IP | | |
| Network | | Router |
| | | |
+---------+ +--+--+--+-----+--+--+--+
A A A A | | |
| | | | | | |
| | | | | | |
+----|----------|--|--|-----|--|--|---------+
| V | | | | | | |
| +-----+ | | | | | | |
| | OSC |<--+ | | | | | | OXC |
| +-----+ | | | | | | | |
| +-V---|--|--|-----|--|--|-----+ |
| | | | | V V V | |
outgoing data port O O O O O O incoming data port
| | | | | | |
-->>-----------------O-----+ | +--O--------------->>--
-->>-----------------O-------------\ +-----O--------------->>--
-->>-----------------O \--------O--------------->>--
-->>-----------------O-----------------------O--------------->>--
incoming lambda | port OXC Fabric port | outgoing lambda
| +-----------------------------+ |
| |
+-------------------------------------------+
(Fig.1) OXC system architecture
o Control channel between OXC switching controllers
This Draft assumes that control channels between OSCs must be
maintained to exchange signaling information. The details of the
mechanisms required are outside the scope of the Draft.
o Gathering of link state information for lightpath computation
Lightpath selection can be calculated based on dynamic measurements
Hahm et al [Page 3]
draft-hahm-optical-restoration-01.txt December 2000
of optical resources that are distributed using link state routing
protocols. Many mechanisms for exchanging the link state information
have been introduced by extending existing routing protocol such as
OSPF or IS-IS LSA[2,3,4,5,6] in the optical network environment.
This Draft assumes these link state information exchange mechanisms.
The minimum link state information required to select lightpaths is
as follows: the information of lambda availability in each link, the
number of unused incoming data ports and unused outgoing data ports
at each OXC. Because the route of a lightpath is decided at the
ingress OXC, the number of unused incoming data ports of the ingress
OXC can be obtained without explicit LSA exchange. However, the
number of unused outgoing data ports of each OXC has to be
distributed.
Every ingress OXC has to know the SRLG (Shared Risk Link Group) value
of every link to compute lightpaths which do not share the same risk
of potential damages. These SRLG values do not change, and so this
information is exchanged only once.
In order to know whether to connect between incoming lambdas and
outgoing lambdas of different wavelengths, the ingress OXC has to
know the availability of lambda converters in all OXCs. Currently,
this Draft simply assumes that all OXCs have enough lambda
converters.
o Triggering of lightpath generation
It is assumed that network management functions will perform
lightpath selection. Therefore, in this Draft we only consider the
signaling procedures after the route of the lightpath has been
determined.
In general the establishment of an LSP in MPLS can be divided into
two cases: pre-establishment before data traffic arrives at the
ingress router, and post-establishment after data traffic arrives at
the ingress router. In the latter case, LSPs must be created quickly
enough to handle the data traffic waiting at the ingress router for
transmission.
However, the creation of lightpath will not in general be so time-
critical, as they will only be created in response to long-term
changes in traffic volume.
In this Draft, the ingress OXC is in charge of the creation,
deletion, and restoration of lightpaths.
o Detection of damaged lightpaths
If an optical link is damaged physically, all the lightpaths passing
Hahm et al [Page 4]
draft-hahm-optical-restoration-01.txt December 2000
through this link will be affected. Generally in case of an all-
optical network not using optical/electrical/optical(OEO) conversion,
damage to a lightpath or drop of light signal level cannot be easily
detected by loss of light alarm. However because the egress OXC
receives the light signal and converts it back to an electrical
signal, any problems arising with the lightpath can be detected
there. Therefore the responsibility for the detection of damaged
lightpaths lies with the egress OXC.
o Strict explicit routing vs. loose explicit routing
In CR-LDP, both strict explicit routing and loose explicit routing
mechanisms may be used. However, in this scheme for lambda switching,
strict explicit routing is preferred to designate the lightpath. By
using strict explicit routing, optical network resources can be
managed more precisely, and the rate of success for lightpath
creation can be enhanced.
o Decision of backup lightpath
In this Draft, we adopt the method of pre-establishment of backup
lightpaths in advance of link failure. This minimizes the
restoration time, especially when the restoration process must be
carried out simultaneously for a large number of damaged lightpaths
sharing the same damaged link.
In this Draft, we choose the 1:N restoration mechanism, where N
primary lightpaths share one backup lightpath. The size of N will
depend on the topological characteristics of the network. We say
that the N primary lightpath and one backup lightpath share the same
restoration group. The weakness of the 1:N restoration mechanism is
that, after an initial failure and before reprovisioning, it cannot
support restoration for additional failures to other lightpaths in
the same restoration group. This defect could be remedied through a
M:N restoration mechanism (M >= 2). Such a mechanism could be
supported through the scheme described here, but will not be
considered further at this time.
To decide on the grouping of primary lightpaths and backup lightpath,
the SRLG values of links are considered. Because a lightpath travels
through several links, it will have corresponding to it the set of
SRLG values of its member links. The lightpaths within a
restoration group cannot share the same set of SRLG value, as then a
single failure could affect several lightpaths simultaneously.
Therefore, when a new lightpath is created, if it cannot be placed
within any existing restoration group, a new restoration group is
created, along with a backup lightpath for the newly created primary
lightpath.
The difference between a primary lightpath and backup lightpath is
Hahm et al [Page 5]
draft-hahm-optical-restoration-01.txt December 2000
that the backup lightpath has no connections between the data port
and lambda port in the ingress OXC and egress OXC, whereas the
primary lightpath has connection in both OXCs. The connections
between these ports are made during the restoration process.
o Release of damaged lightpath
A damaged lightpath must be released in order to make the resources
of its undamaged segments available for future demands. The release
of lightpath resources is the ingress OXC's responsibility. The
released resources can be reused after announcement of their released
status via OSPF or IS-IS LSAs.
o Failure of lightpath creation
The creation of lightpaths can fail for the following three reasons.
First, failure can occur due to an inconsistency between the gathered
link state information at the ingress OXC and the actual link status
of optical network. Because link state information can be transmitted
with some delay from every OXC, delayed updates can make for this
inconsistency.
Secondly, failure can occur even if link state information is
consistent with the actual link status. If two ingress OXCs decide
simultaneously to use the same network resources, one of the
lightpath setup attempts will fail because its resources have already
been claimed by the other lightpath.
Finally, even if lightpath establishment completes, the lightpath may
fail to carry data because the quality of transmission does not reach
a minimal threshold level. The deterioration of transmission quality
can occur due to several reasons[7,8].
The first two cases of failure during lightpath setup are reported to
the ingress OXC by a Lightpath Notification Message from the
intermediate OXCs where the error is noted.
Failure of the last sort can be detected by measuring the SNR of the
received optical signal, or the error ratio of Optical-to-Electric
transformed data. If the quality of the lightpath does not reach the
threshold level, the lightpath is released, and a new lightpath is
created.
4. Procedures for bandwidth provisioning and restoration
In this section, the procedures for bandwidth provisioning and
restoration are described in detail, which include the setup
procedures for primary and backup lightpaths, the reporting procedure
Hahm et al [Page 6]
draft-hahm-optical-restoration-01.txt December 2000
for handling damaged lightpaths, the restoration procedure for
replacing a damaged lightpath with the backup lightpath, and the
release procedure for unused lightpaths.
4.1 Decision of lightpath based on link state information
If the primary lightpath cannot be created within an existing
restoration group, after creating a new restoration group, the
primary lightpath and backup lightpath are created within the newly
created restoration group. If the primary lightpath can be created
within an existing restoration group, no new backup lightpath needs
to be created, so the primary lightpath only is created.
4.1.1 Lightpath setup procedure for primary lightpath
Once the route of a lightpath is decided, the ingress OXC sends the
Lightpath Setup Message to the next intermediate OXC through the
control channel. The sequence of intermediate OXCs and the lambdas
to be allocated for the lightpath are transferred by the Lightpath
Setup Message.
An intermediate OXC receives the Lightpath Setup Message from its
adjacent OXC. The OSC of the intermediate OXC then attempts to
configure the OXC switch fabric according to the Lightpath Setup
Message, and receives the result from the OXC switch fabric. If a
successful result is returned, the OSC of the intermediate OXC
transmits the Lightpath Setup Message to the next adjacent
intermediate OXC. During this procedure, intermediate OXCs consume
the network resources and therefore update the link state
information. This link state information will then be distributed to
other OXC by using OSPF or IS-IS LSAs.
If a Lightpath Setup Message successfully reaches the egress OXC, the
egress OXC then returns the Lightpath Notification Message noting the
successful lightpath creation to the ingress OXC. Upon receiving
this notification message, the ingress OXC announces this increment
in available bandwidth capacity by using OSPF or IS-IS LSA functions
at the IP level. Routers receiving this link status information
apply the increased bandwidth to the generation of LSPs meeting
traffic engineering requirements.
If an intermediate OXC receiving the Lightpath Setup Message cannot
successfully configure the OXC switch fabric, the intermediate OXC
replies with a Lightpath Notification Message indicating the failure
to the ingress OXC. An ingress OXC receiving this reply then sends a
Lightpath Release Message to release any tentatively claimed
resources. The detailed procedure is explained in section 4.3.
The primary lightpath made by this procedure has a lightpath ID
comprising the ingress OXC identifier, a B flag value of 0 indicating
Hahm et al [Page 7]
draft-hahm-optical-restoration-01.txt December 2000
that this lightpath is a primary lightpath, and the outgoing lambda
port in the ingress OXC. This lightpath ID is then used to identify
the lightpath in subsequent messages related to lightpath failure,
restoration, and release.
4.1.2 Lightpath setup procedure for backup lightpath
Backup lightpaths are created through the same procedure as primary
lightpaths. The backup lightpath made by this procedure has a
lightpath ID comprising the ingress OXC identifier, a B flag value of
1 indicating that this lightpath is a backup lightpath, and the
outgoing lambda port in the ingress OXC.
4.2 Procedure for reporting a damaged lightpath
Damage to lightpaths can be detected by the egress OXC. After
detection, the egress OXC issues a Lightpath Failure Message as soon
as possible. The Lightpath Failure Message comprises the ID of the
damaged primary or backup lightpath, and the reason why the
impairment occurred.
4.3 Restoration procedure
Restoration can be applied to a damaged primary lightpath or backup
lightpath.
4.3.1 Restoration procedure for damaged primary lightpath
In case of failure of a primary lightpath, the ingress OXC is made
aware of which lightpath is damaged by the lightpath ID in the
failure message. The ingress OXC then replaces the damaged primary
lightpath with the backup lightpath shared by the same restoration
group.
First of all, the ingress OSC repairs the connection within its own
OXC by replacing the connection between the incoming data port and
outgoing lambda port of the damaged lightpath with that of backup
lightpath. This process is executed internally without exchanging
messages.
As the second step, the ingress OXC sends the Lightpath Restoration
Message. This message has the backup lightpath ID and the egress OXC
identifier. When the egress OXC receives this message, the OSC of
egress OXC finds the outgoing data port for damaged lightpath, and
converts this message into the control command and sends it to OXC
switch fabric to connect between the incoming lambda port and the
outgoing data port in OXC switch fabric. The OXC switch fabric
returns a result status to the OSC. Then the egress OXC of OSC
Hahm et al [Page 8]
draft-hahm-optical-restoration-01.txt December 2000
reflects the result to the Lightpath Notification Message, and sends
this message to the ingress OXC.
Because the backup lightpath is consumed by this restoration
procedure, the new alternative backup lightpath must be created.
This procedure is carried out according to the procedure of section
4.1.2.
4.3.2 Restoration procedure for damaged backup lightpath
The damage of the backup lightpath does not affect to the ongoing
data transfer. However, because the primary lightpaths belonging to
the same restoration group lose the restoration capability, the
alternative backup lightpath must be created as soon as possible.
The procedure for creating alternative backup lightpath is processed
according to the procedure of section 4.1.2.
4.4 Lightpath release procedure for lightpath
The release of a lightpath can take place for several reasons: (1)
the primary or backup lightpath becoming impaired by the damage, (2)
the primary lightpath becoming underutilized due to a decreased
volume of the data traffic, (3) the backup lightpath becoming
unneeded due to the release of all primary lightpaths sharing the
same restoration group, (4) the primary or backup lightpath that is
not proceed its lightpath further due to the occurrence of the error
during the lightpath setup procedure.
A Lightpath Release Message is transmitted to the egress OXC or to
the intermediate OXC which occurred a failure. For this process, the
Lightpath Release Message contains the sequence of intermediate OXCs
that it has to travel and the lambdas to be de-allocated.
An intermediate OXC receives the Lightpath Release Message from its
adjacent OXC. The OSC of the intermediate OXC then attempts to
configure the OXC switch fabric according to the Lightpath Release
Message, and receives the result from the OXC switch fabric. If a
successful result is returned, the OSC of the intermediate OXC
transmits the Lightpath Release Message to the next adjacent
intermediate OXC. During this procedure, intermediate OXCs recycle
the network resources, then update their link state information. This
link state information will then be distributed to other OXCs using
OSPF/IS-IS link state distribution procedures.
If the Lightpath Release Message successfully proceeds all the way to
the egress OXC, the egress OXC notifies the successful result to the
ingress OXC by the Lightpath Notification Message. The ingress OXC
receiving the notification message announces the decrement of
bandwidth capacity through OSPF/IS-IS announcements. Once this new
resource information has propagated through the IGP, the
Hahm et al [Page 9]
draft-hahm-optical-restoration-01.txt December 2000
corresponding link resources can be used in later path selection/
establishment function.
If the intermediate OXC receiving the Lightpath Release Message fails
to affect the release in the OXC switch fabric, an error message is
returned to the OSC and subsequently propagated back using the
lightpath notification message.
5. Message Types
In this section, we define the message types which are used for the
bandwidth provisioning and restoration procedures. These message
types are defined by extending CR-LDP.
5.1 Lightpath Setup Message
A Lightpath Setup Message is issued to create a primary lightpath or
backup lightpath by an ingress OXC. This message is forwarded to the
next intermediate OXC through a control channel on the hop by hop
basis.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Lightpath Setup | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress OXC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| OXC Outgoing Lambda Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath OXC list TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress OXC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Message ID
The message identifier of this message, which is incremented by
one whenever a new message is generated by an ingress OXC,
regardless the generated message type. It is used to specify the
message issued by the ingress OXC to create the lightpath.
- Ingress OXC identifier
The address of the ingress OXC at which a lightpath starts.
- B
If the created lightpath is a backup lightpath, B is set to 1.
Otherwise(a primary path), it is set to 0.
Hahm et al [Page 10]
draft-hahm-optical-restoration-01.txt December 2000
- OXC Outgoing Lambda Port ID
This represents an ID of outgoing lambda port from which the
lightpath starts.
The value of { Ingress OXC identifier + B + OXC outgoing lambda
Port ID } is unique throughout the optical network. Therefore,
this combined value is used to specify the lightpath.
- Lightpath OXC list TLV
It represents the sequence of OXCs comprising lightpath and
lambdas being allocated for a lightpath.
- Egress OXC Identifier
The identifier of the OXC at which the lightpath ends.
5.2 Lightpath Notification Message
This message is used as the response message for the Lightpath Setup
Message, the Lightpath Restoration Message, and the Lightpath Release
Message. An ingress OXC identifies a response message respectively by
comparing the Message ID conveyed by a notification message with the
Message ID which was issued by itself.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Lightpath Notify | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Returned OXC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Message ID
This message ID is the return value of the message ID which is
generated by the ingress OXC. This ID is used to identify the
original messages respectively.
- Returned OXC identifier
The address of the intermediate OXC or egress OXC which issued
this Notification message.
- Result
0: The message which was issued by an ingress OXC is processed
successfully.
1: The designated intermediate OXC does not exist.
2: The designated lambda port does not exist in the designated
intermediate OXC.
Hahm et al [Page 11]
draft-hahm-optical-restoration-01.txt December 2000
3: The outgoing data port does not exist in the designated egress
OXC.
4: The lambda switching function does not exist in OXC.
5: The lambda conversion function does not exist in OXC.
6: The outgoing data port of the designated OXC is used by
another primary lightpath.
7: The release of designated lightpath was failed.
8: The restoration of designated lightpath was failed.
9: Error occurred by an unspecified reason.
5.3 Lightpath Failure Message
This message is generated by an egress OXC to notify error status of
a lightpath. The ingress OXC can identify which lightpath is under
malfunction by the lightpath ID of this message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Lightpath Failure | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress OXC Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| OXC Outgoing Lambda Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress OXC Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Message ID
The message identifier of this message, which is incremented by
one whenever a new message is generated by this egress OXC,
regardless the generated message type. It is used to specify the
message issued by egress OXC to inform the damaged lightpath.
- Lightpath ID
{ Ingress OXC identifier + B + OXC outgoing lambda Port ID } is
used to specify the lightpath.
- Egress OXC Identifier
Address of Egress OXC which detected the damage of a lightpath.
- Result
1: Signal of light was disappeared.
2: Signal level of light was degraded.
3: Error rate of transmitted data exceeded threshold level.
4: Error occurs with an unspecified reason
Hahm et al [Page 12]
draft-hahm-optical-restoration-01.txt December 2000
5.4 Lightpath Restoration Message
This message is sent to an egress OXC by an ingress OXC to restore a
damaged primary lightpath or damaged backup lightpath. When an
ingress OXC receives the Lightpath Failure Message from egress OXC,
it issues this message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Lightpath Restore | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress OXC Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| OXC Outgoing Lambda Port ID (backup) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress OXC Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Message ID
The message identifier of this message, which is incremented by
one whenever a new message is generated by this ingress OXC,
regardless the generated message type. It is used to specify the
message issued by ingress OXC to restore the damaged lightpath.
- Lightpath ID
{ Ingress OXC identifier + 1 + OXC Outgoing Lambda Port ID } is
used to specify the backup lightpath
- Egress OXC Identifier
Address of Egress OXC which detects the damage of a lightpath
5.5 Lightpath Release Message
This message is used to release the established primary lightpath or
backup lightpath. If the intermediate OXCs or egress OXC receive
this message, they release the lambda or outgoing data port
resources.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Lightpath Release | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress OXC identifier |
Hahm et al [Page 13]
draft-hahm-optical-restoration-01.txt December 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| OXC Outgoing Lambda Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lightpath OXC list TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress OXC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Message ID
The message identifier of this message, which is incremented by
one whenever a new message is generated by this ingress OXC,
regardless the generated message type. It is used to specify the
message issued by ingress OXC to release the pre-occupied
lightpath.
- Lightpath Identifier
{Ingress OXC identifier + B + OXC outgoing lambda port ID} is
used to identify the primary lightpath or backup lightpath
which is released by an ingress OXC.
- Lightpath OXC list TLV
Represents the sequence of OXCs comprising released lightpath
and lambdas being allocated for a lightpath.
- Egress OXC Identifier
The address of the OXC at which a lightpath ends.
5.6 Lightpath OXC List TLV
This TLV is used to specify a sequence of the OXCs which are
connected by optical links and lambdas. This TLV is used with the
Lightpath Setup Message and Lightpath Release Message. The sequence
of OXCs is listed from the nearest OXC to the farthest OXC.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type(= Lightpath OXC list) | Length = 8 * n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OXC Identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x| OXC Outgoing Lambda Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OXC Identifier #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hahm et al [Page 14]
draft-hahm-optical-restoration-01.txt December 2000
|x| OXC Outgoing Lambda Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- OXC Identifier
It is used to identify intermediate OXCs through which a
lightpath passes.
- OXC Outgoing Lambda Port ID
It is used to identify an outgoing lambda port
Security Considerations
It is important to maintain secure communication between the OXCs.
However, this Draft does not address the detailed security
consideration. It is reserved for future study.
References
[1] Daniel O. Awduche, Yakov Rekhter, John Drake, and Rob Coltun,
"Multi-Protocol Lambda Switching: Combining MPLS Traffic
Engineering Control with Optical Crossconnect," Internet Draft,
Work in Progress, November 1999
[2] Kireeti Kompella et al, "Extensions to IS-IS/OSPF and RSVP in
support of MPL(ambda)S," Internet Draft, Work in Progress,
February 2000
[3] S. Giacalone, "Network Engineering Extensions (NEXT) for OSPFv3,"
Internet Draft, Work in Progress, August 2000
[4] G. Wang et al, "Extensions to OSPF/IS-IS for Optical Routing,"
Internet Draft, Work in Progress, March 2000
[5] K. Kompella et al, "IS-IS Extensions in Support of MPL(ambda)S,"
Internet Draft, Work in Progress, July 2000
[6] K. Kompella et al, "OSPF Extensions in Support of MPL(ambda)S,"
Internet Draft, Work in Progress, July 2000
[7] Angela Chiu and John Strand, "Unique Features and requirements
for the Optical Layer Control Plane," Internet Draft, Work in
Progress, July 2000
[8] L. Ceuppens, D. Blumenthal, J. Drake, J. Chrostowski, and W.
Edwards, "Performance Monitoring in Photonic Networks in support
of MPL(ambda)S," Internet Draft, Work in Progress, March 2000
Acknowledge
Hahm et al [Page 15]
draft-hahm-optical-restoration-01.txt December 2000
This work has been produced from the joint project between ETRI
(Electronics and Telecommunications Research Institute in Korea) and
NIST (National Institute Standards and Technology).
Author's Address
Jin Ho Hahm
ETRI
820 West Diamond Avenue
Gaithersburg, MD 20899
Phone: 301-975-8400
Email: hahm@antd.nist.gov & jhhahm@etri.re.kr
Kwang-il Lee
NIST
820 West Diamond Avenue
Gaithersburg, MD 20899
Phone: 301-975-8428
Email: kilee@antd.nist.gov
Hahm et al [Page 16]
