One document matched: draft-duroyon-te-ip-optical-00.txt
Internet Engineering Task Force Olivier Duroyon
Rudy Hoebeke
Hans De Neve
Internet Draft Alcatel
Document: draft-duroyon-te-ip-optical-00.txt July 2000
Triggering and advertising lightpaths in an IP over optical network
<draft-duroyon-te-ip-optical-00.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/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
The objective of this draft is to propose an IP service model where
lightpaths are dynamically triggered by the IP layer and
subsequently advertised for IP routing. The network model assumes
that several IP service domains, some of which represent different
administrative entities, share the same optical backbone and
focuses therefore primarily on an overlay model. Therefore, this
draft intends to complement the IP over optical framework with
respect to the overlay model.
2. 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 RFC2119.
3. Introduction
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 1
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
This draft introduces an end-to-end IP service model enabling the
dynamic management of optical lightpaths by means of MPLS
signaling.
For reasons of definiteness, the optical devices are always
referred to as optical cross-connects (OXCs) and the IP devices as
routers. The terminology used in the draft attempts to be in line
with the definitions found in [ip-optical].
Service model issues raised in this draft apply mainly to an
overlay/peer model although some of them equally pertain to an
integrated model.
An overlay model is appropriate for an untrusted environment where
several IP service domains, representing different administrative
entities, share the same optical backbone. Moreover it seems well
suited for a network architecture including non-IP devices, e.g.,
legacy TDM or ATM equipment, that interface with the same optical
backbone. This is however beyond the scope of this draft.
The concept of an overlay/peer model has been introduced in [ip-
optical] but allows for several diverse interpretations. Our
understanding of the overlay model is based on the following
characteristics, which are largely defined in other contributions
(ODSI, OIF and IETF drafts):
- Typical for an overlay model is that any addressing scheme may be
used within the optical domain, even non-IP based. However, in this
draft, public IP addressing is assumed for any addressable entity
(OXC, control channels and lightpaths or bundle of lightpaths when
lit up).
- One (or more) IP interface(s) used as control channel(s), called
Optical-User Network Interface(s) (O-UNIs), are defined for each
router interfacing with an OXC. These devices are hereafter
respectively referred to as boundary router and boundary OXC.
- These control channels can be associated with one (or more) of
the boundary router's physical ports, interconnecting with the
boundary OXC (when sub-rate bandwidth connections are supported on
a physical interface, this association could be at the level of
sub-rate channels, e.g., SONET containers). These ports (or sub-
rate channels) are hereafter generically referred to as IP-capable
end-points. A lightpath is defined as the entity formed by two IP-
capable end-points and their interconnecting path across the
optical domain.
- In the optical domain, the control channels are terminated on an
OXC-Controller (OXC-C). An OXC-C is a device processing any kind of
control channel messages and controls the lightpath setup in an
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 2
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
OXC. An OXC-C can be integrated in a single OXC or remotely control
one or more OXCs.
- Routing protocol messages (such as IGP or EGP) are not exchanged
across the O-UNI.
- Boundary router reachability across the optical domain is
achieved via a service discovery mechanism across the O-UNI in
conjunction with either a directory service or an IGP across the
optical domain, denoted as optical IGP (O-IGP).
- A boundary router (or some other device connected to the boundary
OXC) can issue a lightpath request through extended RSVP or CR-LDP
across the O-UNI. Fundamental lightpath requests are the
establishment of a new lightpath or the tear down of an existing
lightpath, although other requests can be envisioned (e.g.,
requests to change some attribute of a lightpath). We refer to all
these as lightpath requests.
- In case of an untrusted O-UNI, any lightpath request coming from
the boundary router has to be authenticated and validated by the
optical domain.
- A lit-up lightpath is advertised as an IP link in the IP service
domains or is added to an existing IP link (forming a bundle).
- IP destination reachability is subsequently achieved by
exchanging IP routing messages across lightpaths.
- Traffic Engineering-Label Switched Paths (TE-LSPs) for the
purpose of IP traffic engineering may be created on top of
lightpaths.
Our service model further assumes that a decision point in the IP
service domain, e.g., a Traffic Engineering (TE) tool, will trigger
a boundary router to issue a lightpath request towards the optical
domain. The decision point determines the need for a lightpath on
the basis of IP Service Level Agreements (IP-SLAs) and related
information, such as for instance load measurements in the IP
service domain.
In the remainder of the document, the terms TE tool or decision
point are used interchangeably and refer to the IP service domain
device, capable of triggering lightpath requests.
4. IP service model description
This section outlines the sequence of events that characterize our
proposed IP service model.
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 3
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
(1) Provisioning
Provisioning consists of installing and configuring interfaces
between boundary OXC and boundary routers. At this stage, an
association is configured between the control channels and one (or
more) of the boundary router's IP-capable end-points.
In case of our overlay model, the control channel is identified by
a numbered IP address and forms an IP link with an OXC-C. This IP
link is not announced into the IGP routing realm of the IP service
domain but is only advertised into the optical domain.
(2) Optical Service Level Agreements
Next, the service model consists of negotiating Optical SLAs (O-
SLA) at optical domain-IP service domain boundaries. In case of an
untrusted peering relationship, each lightpath request is
authenticated and validated against the O-SLA.
(3) Service Discovery
A service discovery mechanism across the O-UNI, as defined for
example in ODSI, provides the necessary reachability information to
the IP service domain for the authorized Closed User Groups (CUGs).
In addition, specific optical characteristics of the IP-capable
end-point are learned, such as, e.g., sub-channel size or O-UNI
restoration capabilities.
(4) Lightpath request
The decision point of the IP service domain determines the required
connectivity through the optical domain based on service
requirements as per the IP SLAs. It then triggers the boundary
routers to launch a lightpath request towards the associated
boundary OXCs, using MPLS-based signaling. This process is dynamic
and may involve, amongst others, the set-up of additional
lightpaths, release of existing lightpaths or redirection of
existing lightpaths.
(5) Optical path selection
In case an O-IGP is used inside the optical transport network, each
boundary OXC learns the complete topology of the optical domain. A
Constraint-based Shortest Path First (CSPF) algorithm can then be
implemented in the boundary OXCs to calculate a route for the
lightpath in line with the constraints specified in the request. As
an example, the route of a lightpath may depend on the
protection/restoration requirements or routing constraints
specified in the lightpath request. The latter may indicate that
the requested lightpath should be routed diversely from other
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 4
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
lightpaths. This CSPF algorithm is expected to be quite different
from an IP CSPF algorithm because of optical considerations.
(6) Lightpath advertisement to the IP layer
As soon as the lightpaths are lit up, they are advertised to the IP
layer. The involved boundary routers will either create a new IP
link and start to exchange routing information (using IGP or eBGP)
or modify the characteristics of the existing IP link.
(7) Traffic engineering for optimization of the optical domain
Optionally, the optical domain may have its own off-line Optical
Traffic Engineering (O-TE) tool. This tool may be used for
optimization of resource utilization in the optical domain by
rearranging some lightpaths.
5. Optical Service Level Agreements
As mentioned before, lightpath requests issued by a boundary router
are only accepted within the constraints of an O-SLA. An optical
domain-IP service domain boundary coincides with an O-UNI with its
associated O-SLA. Similarly, if there are multiple optical
subnetworks in the optical domain, there will be O-SLAs negotiated
at each optical subnetwork boundary. An optical subnetwork boundary
then corresponds to an Optical Network to Network Interface (O-
NNI). In this draft, we limit the discussion to O-SLAs at the level
of O-UNIs.
Additionally, we only discuss the technical aspects of an O-SLA.
Borrowing from the terminology introduced in [diffserv-framework],
we refer to the technical part of an O-SLA as an Optical Service
Level Specification (O-SLS). An O-SLS is considered to be
unidirectional and to specify performance expectations (i.e., the
service level) for the IP service domain as well as imposed
reachability constraints, e.g., CUG.
O-SLS parameters could for example include:
1. Capacity constraints
An ingress O-SLS may contain limits on the maximum number of
lightpaths that can be established from a specific ingress point,
possibly as a function of time of day, as well as bandwidth
constraints (OC-48, OC-192, etc.).
An egress O-SLS may put capacity constraints on the lightpaths that
the receiving IP service domain is willing to terminate.
2. Service performance parameters
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 5
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
Examples are lightpath latency, supported protection/restoration
options, reliability, availability, supported routing constraints,
accessibility (i.e., lightpath request blocking probability),
responsiveness (specifying upper limits on the processing time of
lightpath requests), etc.
3. Constraints on the 'scope' of lightpath request
This may be viewed as an extension to the concept of CUGs, which by
nature already exhibit reachability limitations. Scope constraints
are intended to additionally restrict the topological extent of
lightpaths. In its simplest form, the O-SLS offers to accept any
lightpath request issued by the IP service domain over a specific
O-UNI up to a maximum capacity without any scope constraint within
the CUG (so-called hose O-SLS). Conversely, the agreement may be
constrained by the egress point of a lightpath. For example, the
optical domain service provider might agree to the setup of
lightpaths, up to a certain maximum capacity, but only if these
lightpaths are destined to a specific set of egress points within
the CUG.
Part of the purpose of O-SLSs is to protect resources in the
optical domain by validation of submitted lightpath requests. If
the optical domain and the IP service domain are under control of
the same administrative authority, then there is likely to be a
trusted peering relationship between both domains. Conversely, in
case of an untrusted peering relationship, the optical domain
service provider validates incoming lightpath requests as per the
O-SLS. This validation process can be implemented in the OXC-C. In
this case, there exist several mechanisms to install an O-SLS in an
OXC-C, e.g., CLI, SNMP, LDAP or COPS. Alternatively, the O-SLS
enforcement may be outsourced to another policy entity.
An O-SLS offers to accept lightpath requests at the service level
agreed with the IP service domain. The optical domain service
provider will provision the optical domain accordingly. A broad
range of optical services could be envisioned. As an example,
services could be defined with different levels of accessibility,
depending on the probability that a lightpath establishment request
is blocked. Moreover, services could also be categorized as
protected or non-protected, depending on the offered protection
level. All of these service level characteristics influence the
resource provisioning process in the optical backbone.
For each lightpath request, the optical domain service provider may
also need to identify the O-SLS for which the request is submitted.
Some authentication may be included in the request in order to
verify that the rightful IP service provider issued the request. In
some cases, this customer might be implicitly derived from the
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 6
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
control channel on which the lightpath request was received. The
authentication mechanism must be specified in the O-SLS.
Although it can be assumed that O-SLSs will be static for the
foreseeable future, this draft does not preclude dynamic O-SLSs.
These would necessitate some automated form of interaction between
the IP service domain and the optical domain. In case of an O-SLS
at the O-UNI, this may for instance require the interaction between
a Bandwidth Broker (BB) in the IP service domain and a Lambda
Broker (LB) in the optical domain. At the level of an O-NNI, this
would be between different LBs, acting on behalf of the different
optical subnetworks. This automated (re-)negotiation of O-SLSs
would in turn call for an automated O-SLS admission control
function. Note that this admission control function is different
from the validation of lightpath requests as per the negotiated O-
SLS, referred to as O-SLS enforcement.
6. Lightpath triggers
As stated in [ip-optical], the lightpath request triggering process
should be part of a stable traffic engineering tool in the IP
service domain as opposed to a data-driven shortcut approach,
similar to the schemes proposed for IP over ATM networks.
Henceforth, an integrated TE-LSP and lightpath triggering process
is proposed at the end of this section to alleviate the
shortcomings of the former method and is elaborated below.
6.1 Data-driven shortcut approach for lightpaths
The data-driven shortcut model would imply that the boundary
routers use traffic measurements to autonomously control the number
of lightpaths that connect them with a set of remote boundary
routers across the optical domain. For example, boundary router A
could detect that some of its traffic is reaching boundary router B
in a multi-hop way. If this traffic trunk is large enough, boundary
router A might decide to set-up a lightpath to boundary router B,
relieving the IP forwarding at all intermediate routers on the
multi-hop path. In an overlay model, once a lightpath has been
established to a new destination, it should be announced as a (new)
IP link in the IP service domain routing database. As such, it can
be used by any TE entity in the IP service domain and this IP link
may carry several TE-LSPs. This means that the TE entity in the IP
service domain would then be constantly reacting to decisions of
the boundary routers that are continuously changing the IP
topology.
Such a layered scheme of lightpath requests and TE-LSP requests is
inefficient and could also break the TE service model, when the
only available lightpath between two boundary routers would be torn
down. Such a decision might be based on the valid observation that
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 7
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
the traffic pattern has changed such that the existing lightpath is
under-utilized and may be re-directed towards another boundary
router. However, the lightpath might still carry TE-LSPs. Turning
off the lightpath has the effect of a link failure and will hence
trigger the TE entity in the IP service domain to recover from this
failure. Depending on whether the TE-LSP was protected or not, one
of the following scenarios will take place.
6.1.1 Protected TE-LSPs
TE-LSPs can be used to carry mission critical traffic requiring a
fast recovery scheme in case of link failures. Upon such an event,
the traffic of the working TE-LSP can be switched to a protect TE-
LSP that has been pre-configured along a node- and link-disjoint
path.
- Protected lightpath: if the turned-off lightpath was protected
within the optical domain, the TE-LSP path calculation might have
selected this IP link for both the working and the protect path of
the TE-LSP. In that case, the TE-LSP protect path will not be
available and connectivity will be lost.
- Unprotected lightpath: in this case the problem would not arise
since the route diversity TE-LSP protect scheme would have selected
another IP link for the protect path.
6.1.2 Unprotected TE-LSPs
If the TE-LSP was not protected, the source nodes of the TE-LSPs
running over the turned-off lightpath will start a CSPF calculation
to find an alternative path. As all source nodes will be competing
for the same resources, some LSP requests will be blocked and it
might take a while before all LSPs have been restored.
The above scenario equally pertains to the case of any link failure
in an IP service domain. However, link failures in an IP service
domain may be considered as rare events. This is however not the
case when this link failure behavior is the result of a data-driven
shortcut approach across an optical backbone.
6.2 Integrated TE-LSP and lightpath triggering process
Given the above shortcoming, boundary routers should not
autonomously decide to tear down a lightpath. Yet, it may not
always be appropriate to maintain an under-utilized lightpath.
However, a lightpath should not be turned off until the TE-LSPs it
carries have been re-routed along an alternative path. This might
even require that a new lightpath is set up between two other
boundary routers. All of this calls for a co-ordinated TE-LSP and
lightpath triggering process, integrated in the same decision
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 8
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
point. This is possible since both responsibilities reside within
the IP service domain.
The ability to dynamically establish lightpaths adds an extra
dimension to the TE capabilities of an IP service domain. In
addition to forwarding packets along non-shortest paths, it is now
also possible to (re-)configure the topology of the IP service
domain by means of adding, deleting or changing lightpaths across
the optical backbone.
This integrated decision point will use the set of IP SLAs and the
derived traffic trunk requirements across the IP service domain
(possibly complemented with traffic measurements) to determine the
optimal set of lightpaths and TE-LSPs. Optionally, the explicit
path calculation for the TE-LSPs could still be left to the routers
running a CSPF algorithm within the topology, as determined by the
decision point.
7. Lightpath advertisement to the IP layer
The decision point may thus trigger the set-up of an additional
lightpath to an already connected boundary router. Alternatively,
it may trigger a rearrangement of existing lightpaths, or the
establishment of a lightpath to a boundary router that could
previously not be reached through the optical domain. It might very
well be that the decision point triggers a boundary router to drop
a lightpath if its capacity is no longer needed to meet the
requirements of the IP SLAs.
In order to make efficient use of the dynamicity of lightpath
requests, the routing protocol parameters should be dynamically
configurable as well. This section outlines a proposal to achieve a
seamless integration of a new lightpath within the IP service
domain for the overlay model by means of automatic configuration.
As soon as a lightpath to a particular boundary router has been lit
up, it is assumed that it is promoted to an operational IP link. In
case of, e.g., regular SONET framing, this is achieved by running
PPP on the newly established lightpath.
7.1. Lightpath set-up to a previously unreachable boundary router
The draft [kompella] defines the different facets of the creation
of an IP link in case of an integrated model and proposes to use
the newly established IP link as a forwarding adjacency in the IP
service domain.
The overlay model imposes different requirements on the IP layer of
the boundary routers. Indeed, once the first lightpath is
established between two boundary routers and promoted as IP link,
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 9
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
it is to be advertised as a point-to-point link for IP routing in
order to initiate the IP connectivity between the two boundary
routers. And subsequently it will allow IP reachability between the
associated IP service domains.
Two cases must be considered. The lightpath is promoted to an IP
link connecting:
- two boundary routers of the same Autonomous System (IGP peering),
or,
- two boundary routers of different Autonomous Systems (eBGP
peering).
The IGP and BGP peering cases do not require the same kind of
configuration and are described separately.
Note that in case of an IGP peer, it is necessary that the
lightpath be bi-directional, because IGP protocols require a bi-
directional transport layer. However, this is for further study
[saha-rsvp].
From an addressing point of view, the IP-capable end-points can be
unnumbered (and, e.g., identified by the Router Id of the boundary
router), or numbered through provisioning, but different from the
control channel IP address.
It has to be noticed again that the control channel identification
is neither known nor advertised throughout the IP service domain.
7.1.1. IGP support
Once the first IP link is established between two boundary routers
and configured to support an IGP peer, the boundary routers need to
get the proper information:
- The first requirement is to select IS-IS or OSPF for the newly
formed IP link.
- In addition, link routing parameters such as timers and area
numbers might have to be specified. For instance, timers in OSPF
should be consistent at both ends of the IP link.
- Also, link metrics (e.g., resource classes, etc.) need to be
inherited or configured for use by IP routing.
- Finally, the IGP protocol is enabled and the IP link is
advertised.
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 10
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
These parameters have to be accessible and are automatically
configured (prior to or at the time of lightpath establishment) by
the decision point of the IP service domain to efficiently deploy
the IP service on top of the lightpath.
However, some of the routing parameters (e.g., OSPF timers) may be
defaulted to pre-determined values. Those values must be defined
network-wide and be consistent between all possible boundary router
pairs. The decision point should be allowed to overwrite those
parameters at the setup time of the lightpath.
7.1.2. eBGP peering
In the case of an inter-AS lightpath, static route configuration
specifying the BGP peer (most probably a virtual interface of the
remote boundary router) should be configured in the local boundary
router in order to set up the TCP session used in BGP.
In addition, an IP SLA is going to be negotiated between the
autonomous systems and routing policies are going to be configured
on both ends of the lightpaths.
As opposed to the IGP peering case, triggering of inter-AS
lightpaths will very likely not arise from an automated process
because of the BGP peering negotiation procedure.
7.2. Set-up of an additional lightpath
In addition to the option described in 7.1 (creation of a new
stand-alone IP link with the new lightpath and advertisement to the
routing protocol), a second option is now possible, which is to add
a supplementary lightpath to an existing IP link that forms a
bundled link [kompella-bundle]. In this case there is no new
configuration necessary for the IGP or BGP routing layer but only
interactions internal to the boundary routers.
This bundle is advertised as a single IP link. The lightpath in
itself may be unidirectional, and hence the bundle could have an
asymmetric bandwidth.
- The boundary router upgrades the bandwidth of the bundle link
based on the characteristics of this new lightpath.
- The new lightpath is included in the load balancing mechanism
that distributes the traffic amongst the component lightpaths of
the bundled link, e.g., proportional to their bandwidth.
- The addition of a new lightpath to a bundle does not impact the
routing topology. Only the new bandwidth of the IP link is
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 11
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
advertised within the IP service domain. The other characteristics
of the IP link, e.g., the resource classes, remain unchanged.
In the case described in this section, the only mandatory
information to be automatically configured by the decision point is
the bundle identifier to which the lightpath is to be added.
7.3. Rearrangement of an existing lightpath
This case is the straightforward combination of lightpath tear-down
followed by a new lightpath set-up.
8. References
[diffserv-framework] Y.Bernet et al, "A Framework for
Differentiated Services", draft-ietf-diffserv-framework-03.txt,
Internet Draft, Work in Progress, February 1999.
[ip-optical] James Luciani et al., " IP over Optical Networks _ A
Framework", draft-ip-optical-framework-00.txt, Internet draft, Work
in Progress, February 2000.
[kompella] K. Kompella et al., "Extensions to IS-IS/OSPF and RSVP
in support of MPL(ambda)S", draft-kompella-mpls-optical-
00.txt,Internet Draft, Work in Progress, February 2000.
[kompella-bundle] K. Kompella et al., "Link bundling in MPLS
traffic engineering", draft-kompella-mpls-bundle-01.txt, Internet
Draft, Work in Progress, June 2000.
[saha-rsvp] D. Saha et al., "RSVP extensions for Signaling Optical
Paths", draft-saha-rsvp-optical-signaling-00.txt, Internet Draft,
Work in Progress, March 2000.
9. Acknowledgments
The authors would like to thank Emmanuel Desmet, Sitaram
Kalipatnapu and Gert Grammel for their constructive comments.
10. Author's Addresses
Olivier Duroyon
Alcatel USA
45195 Business Court
Dulles
Phone: (703) 654 8605
Email: olivier.d.duroyon@usa.alcatel.com
Rudy Hoebeke
Alcatel Bell
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 12
Internet Draft draft-duroyon-te-ip-optical-00.txt July 2000
Francis Wellesplein 1
2018 Antwerp, Belgium
Phone: (32) 3/240.84.39
Email: rudy.hoebeke@alcatel.be
Hans De Neve
Alcatel Bell
Francis Wellesplein 1
2018 Antwerp, Belgium
Phone: (32) 3/240.76.94
Email: hans.de_neve@alcatel.be
Duroyon, Hoebeke, De Neve Expires: January 2001 Page 13
| PAFTECH AB 2003-2026 | 2026-04-24 04:16:56 |