Internet DRAFT - draft-ashwood-ccamp-gmpls-constraint-reqts
draft-ashwood-ccamp-gmpls-constraint-reqts
Network Working Group Peter Ashwood-Smith(Nortel)
Internet Draft Don Fedyk(Nortel)
Vik Saxena(Comcast)
Expiration Date: January 2006
July 2005
Link Viability Constraints Requirements for GMPLS-enabled Networks
draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 describes requirements for connecting a pure photonic
sub-domain to a GMPLS-based Label Switch Router. One of the main
requirements is to avoid advertising all the physical properties of
the underlying optical hardware while still peering with standard
GMPLS. This draft discusses the requirements for abstracting the
optical topology and the implications of various abstract models.
This draft discusses possible extensions to [OSPF-TE] [GMPLS-
Routing] and [ISIS-TE] for use by GMPLS networks that require
additional constraints to be considered in the computation of viable
paths.
P. Ashwood-Smith, Editor Draft 1
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
Table of Contents
1. Introduction....................................................2
2. The Optical Network Interface Requirements......................3
3. Abstract Topologies and Constraints.............................4
3.1 A logical or abstract Cloud....................................5
3.2 A logical/abstract GLSR........................................7
3.2.1 Scalability of an Abstract GLSR..............................9
3.3 Full GMPLS topology...........................................10
4. Path Computation Considerations................................10
4.1. Diverse path pair computation................................10
5. Security Considerations........................................11
6. IANA Considerations............................................11
7. Intellectual Property Considerations...........................11
8. References.....................................................11
9. Acknowledgements...............................................12
10. Author's Addresses............................................12
11. Disclaimer....................................................13
12. Copyright Statement...........................................13
1. Introduction
The motivation for this work comes from pure photonic GMPLS network
sub-domains in which the computation of a viable path may require
the head end GLER/GLSR (or PCE) to consider numerous physical
properties of the fiber, amplifiers, lasers etc. The photonic sub
domains are possibly quite large and physically dispersed.
This draft describes requirements and possible solutions to how a
pure photonic sub-domain may be abstracted using GMPLS. The
requirements are driven by the need to interface the optical network
to the packet network and still represent a viable view of the
blocking in the optical network.
The goal is to allow the vendors of pure photonic devices to keep
the complexity and ever changing physics of their individual and
composite photonic components out of the parts of the GMPLS network
while still permitting GLERS and GMPLS capable routers to compute
viable photonic paths, backup paths, diverse paths etc. In fact the
whole network could be considered a GMPLS network with different
levels of granularity.
While motivated by pure photonic domains, the ability to constrain
certain input link to output link pairs as viable cross connections
is useful in other GMPLS domains such as a TDM ring. TDM rings also
present challenges to a Constrained Shortest Path First (CSPF) style
path computation due to additional blocking constraints.
A requirement is that any proposed extensions can also be used in
the context where a GLSR is deployed as L1VPN-based photonic
abstract node [L1VPN-FRMK][L1VPN-GVPN]. Indeed, the link to link
viability constraint can be used by client edge nodes and client
P. Ashwood-Smith July 2005 2
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
internal nodes to compute only viable l1vpn paths that cross the
GLSR abstract node.
2. The Optical Network Interface Requirements
The GMPLS architecture [GMPLS-ARCH], drafts and RFCs are designed to
permit a router to act as an edge device (GLER) into a lambda, fiber
or TDM switched core of GLSR devices. If paths are to be initiated
by the GLER or even neighboring routers the GLER must be able to
compute a viable path through the lambda, fiber or TDM switched core
and subsequently signal the path via RSVP-TE [GMPLS-RSVP] with a
high degree of probability that the path will be viable. While the
path details itself may be abstracted or loose, the choice of the
interface nodes and links ingress and egress is dependent on the
ability of the sub network domain to satisfy the path request. In
simple terms the routers must have a reasonable view of the topology
to request a path in the first place.
The normal mechanisms of MPLS traffic engineering also apply to
GMPLS where the router uses a slightly modified Dijkstra (CSPF) to
compute a shortest path against a link state advertised topology
database. These current GMPLS conformant implementations may only
advertise and consider two kinds of constraints against the
topology. The first is a simple graph clipping operation, where the
set of links that are allowed in the final solution may be reduced
by considering the link properties required by the LSP and comparing
them with link properties advertised by the GLSRs. After the graph
is sub-graphed/clipped a standard min-sum Dijkstra (or other)
calculation is performed to compute the shortest path from among the
remaining eligible links and nodes.
Such CSPF style algorithms and data are sufficient to deal with most
path computation problems encountered with stat-mux and TDM
switching. However when we consider fiber and wavelength switching,
far more data is required to compute viable photonic paths.
In order to compute if a photonic path is viable from some laser to
some detector we require careful consideration of most of the
following factors (and more):
- Distance and SNR
- wavelength
- fiber type
- amplifier location, type and gain
- laser type
- detector type
- number of switching points
- loss per switching point
- All the OTHER LSPs that traverse every segment we want to use and
their power levels.
P. Ashwood-Smith July 2005 3
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
Each of these factors presents difficulties for a simple min-sum
algebra CSPF algorithm because the optimum or even a viable solution
is likely to require substantially more than the O(Nlog(M)) run time
of a typical CSPF algorithm and would require detailed physics based
models of each device and all the LSPs currently placed in the
network and advertisements of those parameters. The physics is
highly dependent on the given manufacturer and will vary over the
lifetime of the component.
It is none-the-less possible to run detailed physical models of a
photonic domain of many interconnected photonic devices and compute
with a high degree of certainty the viability of any given path, it
is probably however pre-mature to attempt to standardize all of
these attributes and the algorithms required to optimize based on
those attributes. This is because they are highly vendor specific
and are likely to change quickly as new advances in photonics are
made.
A photonic network spanning hundreds or thousands of kilometers,
with amplifiers, OXCs, OADMs and other pure photonic devices can
logically be partitioned into regions or sub-domains each of which
is represented as an abstract topology with various inputs and
outputs.
There exists an optical controller or set of optical controllers
which have the ability to talk directly to all of the devices in its
domain and to manipulate any of their controllable parameters. For
example they can adjust amplifier gain, can establish input output
switching relationships for the OXCs, can control add/drop
properties of OADMs etc. The controllers can further predict for any
input fiber / wavelength, what are the possible output fiber /
wavelength possibilities. The controller does this by running the
detailed physics models of its sub-domain to predict what will work
and what will not work and considers all of the factors listed above
(and more) to determine a viable set of solutions.
In the interim, we wish to find a way that these detailed physical
models may interwork with a simpler but fully standardized GMPLS
architecture such that routers, GLERs, GLSRs or PCEs may compute
routes that traverse photonic domains with a high degree of
certainty that the computed routes will actually work.
3. Abstract Topologies and Constraints
This section covers some possible abstractions of the optical
topology that would be compatible with a GMPLS network. The object
is to explore the ramifications of representing the photonic network
as an abstract topology. The purpose of describing it here is to
explore the feasibility of standardizing new TLVs for interfacing to
optical networks.
Parameters that are valuable in an abstract topology view are:
P. Ashwood-Smith July 2005 4
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
-Path viability at any wavelength
-Path viability at a particular wavelength
-Path Cost
-Path Diversity given a constraint path
The use of wavelength is dependent on the type of equipment. Some
equipment has links that can perform wavelength tuning while other
can only operate at a specific fixed wavelength. Of course, many
wavelength-tunable links are only capable of adjusting through a
limited range, so being wavelength-tunable does not guarantee non-
blocking due to wavelength constraints. Wavelength-tunable links
are currently more expensive that wavelength-fixed links so a
network of wavelength-fiexd links will be common for some time.
Path cost is an arbitrary metric. The Cost is a weight that is
administratively applied to the links in a network. This cost would
be compatible with the GMPLS metric. Internally the optical system
will keep multiple costs for more detailed calculations.
Diversity is typically dealt with in GMPLS using Shared Resource
Link Groups (SRLG). The object of adding this parameter would allow
existing paths to be queried for SRLG identifiers that could be
applied as constraints on other paths. Another requirement would be
to request multiple diverse paths (typically two) at a particular
time.
In terms of the topologies supported the optical network can be
described in terms of:
- A cloud connecting GLERs with a metric.
- A logical switch or abstract GLSR connecting GLERs with logical
links and metrics.
- A physical topology with internal links and nodes.
In the following sections we out line the pros and cons of some of
these abstract views.
3.1 A logical or abstract Cloud
In this model the minimum amount of information is conveyed to the
GLER. The information is in the form of Reachable IP nodes and a
metric. This would be very similar to an interdomain model using
BGP.
The information provided by this model is simple that a path to the
destination IP node is "likely" given a particular wavelength (or
set of wavelengths) and the best metric.
P. Ashwood-Smith July 2005 5
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
The advantage of this system is it provides a minimum exchange of
topology information. The big savings in this scheme is the number
of wavelengths can be abstracted away form the advertised view.
GMPLS signaling [GMPLS-SIG] would have to use the label set to prune
the list of viable wavelengths at setup time.
The drawback of this scheme is that signaling must be able to
resolve the actual wavelength and path. The Path is in fact a loose
path and the underlying optical system has to calculate the path.
There may be cases where a path is not viable even though the remote
node is advertised as reachable. This is a result of the situation
where new paths are set up they may create blocking in the optical
network that can change the reachable paths. It is non-trivial
calculate the resultant changes in connectivity so this will take
time to disseminate. Wavelength-fixed links create more of a
problem since they are more likely to create blocking. A typical
configuration would have wavelength-fixed links from GMPLS routes
going into a device capable of wavelength conversion then into the
blocking optical network to reduce blocking at the edges and in the
core.
------\
GMPLS ----/ | GMPLS
Router 1 --------- / |--------- Router 3
| ---/\
GMPLS \ / -------------\ GMPLS
Router 2 ------------\ /-------------------- Router 4
----
Figure 1 Logical/Abstract Cloud
A) Matrix B) Reachable list
GLER ID | 1 2 3 4
-----------
1 | 0 20 2 6 1 -> {2@cost 20,3@cost2,4@cost6}
2 |20 0 9 0 2 -> {1@cost20,3@cost9}
3 | 2 9 0 8 3 -> {1@cost2,2@cost9,4@cost8}
4 | 1 0 8 0 4 -> {1@cost8,3@cost1}
4 |10 0 0 0 4 -> {1@cost10}
Figure 2 Logical/Abstract Cloud interface
The information can be thought of as a next hop table or a vector
list. Since node 4 has two costs only the minimum cost may be
advertised.
One could envision that a path vector similar to BGP could be built
for multiple domains.
P. Ashwood-Smith July 2005 6
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
3.2 A logical/abstract GLSR
This model expands the logical cloud by specifying the optical link
connectivity in more detail. Extra information of the viability of
the ingress and egress is added and distributed to the GLERs to
allow more visibility into viability and wavelength control while
still hiding the optical parameters.
An abstract node in this architecture is called a logical-GLSR. This
logical-GLSR runs normal GMPLS protocols to its neighboring physical
GLERs, GLSRs or other logical-GLSRs and so to the rest of the GMPLS
network appears as a normal single node.
GMPLS CP +---------------+ GMPLS CP
-----------| Controller |----------
+---------------+
| Control Interfaces (Not Specified)
|
Abstract-GLSR 1| |2 | 3| |4
+-------------|-|------|-|------------+
| | | | | |
| [OEO] [OEO] |
| | | | | |
16---- [OEO] -- [OXC] -- [OXC] -- [OEO] ---5
15---- [ ] -- [ ] -- [ ] -- [ ] ---6
| | | | | |
14---- [OEO] -- [OXC] -- [OXC] -- [OEO] ---7
13---- [ ] -- [ ] -- [ ] -- [ ] ---8
| | | | | |
| [OEO] [OEO] |
| | | | | |
+-------------|-|------|-|------------+
12| |11 10| |9
Figure 3 Optical sub-domain abstracted as a GLSR
This form of abstraction neatly separates the problems of
physics/viability, from those of reachability/desirability. The
physics/viability is handled within the sub-domain and the
reachability/desirability is handled at the router/GLSR level.
P. Ashwood-Smith July 2005 7
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
The viable set of solutions is kept up to date in semi real time
such that the logical GLSR always knows what inputs may be connected
to what outputs. This can be logically thought of as a wavelength to
wavelength connectivity matrix.
1 2 3 4 5 6 7 8 9 10111213141516
1 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1
2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
15 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
16 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Figure 4 Abstract GLSRs link to link viability matrix
For example, if the GLSR in Figure 1 has 16 inputs and outputs it
can compute the viability for each input/output links and produce a
matrix to express what can connect to what (like the above viability
matrix). The matrix initially may be quite dense but would become
more sparse as fewer options are available. In essence this matrix
represents the blocking state of the GLSR.
The logical GLSR will receive RSVP-TE signaling [GMPLS-SIG] messages
and will either allocate a working egress to ingress link pair, or
if explicitly signaled will verify that the requested ingress /
egress link pair are currently viable. Once it has determined what
input/output links are to be used, and that they are viable, it will
communicate with the optical sub-components to create the cross
connection. The RSVP-TE path message may either wait for
confirmation or continue to the next GLSR while the photonic sub-
domain operates in parallel. The logical GLSR may optionally
configure its optical sub-domain on the reverse RESV message.
Unfortunately, the GLER/router/PCE may not compute a viable path
unless it too knows about the input to output link viability and
factors it into its CSPF computation. This is because all the GMPLS-
TE/CSPF computations assume non-blocking nodes (GLSRS) and have no
way currently to know that certain un-numbered link pairs are not
viable. The assumption is that if we can reach one side of a node we
can reach the other but this is no longer true with an abstract-
GLSR.
Therefore, the logical GLSR SHOULD advertise in its link state
updates, the current set of possible outputs for any input link
which may have restrictions on viable input / output combinations.
If the logical GLSR does not advertise a set of viable output links
for an input link, the GLER/router/PCE MUST assume that all output
links are viable, i.e. the normal (G)MPLS-TE behavior which implies
it's a non-blocking link.
The GLSR may choose between the full matrix or sparse set
representations to pick the most space/bandwidth efficient.
P. Ashwood-Smith July 2005 8
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
In summary we support two mechanisms for advertising viability, the
first is to advertise matrix rows and the second the viable elements
(sparse) of that row. In each case, the elements contain a cost
which for efficiency is kept to a small number N of bits. Therefore
the matrix not only gives viability but a cost which can be
incorporated into the path computation. A cost of zero in the matrix
means unreachable as opposed to 0 cost.
A) Matrix B) Reachable list
Link | 1 2 3 4
-----------
1 | 0 4 2 1 1 -> {2@cost4,3@cost2,4@cost1}
2 | 4 0 9 0 2 -> {1@cost4,3@cost9}
3 | 2 9 0 1 3 -> {1@cost2,2@cost9,4@cost1}
4 | 1 0 1 0 4 -> {1@cost1,3@cost1}
Figure 5 Abstract GLSRs link to link viability matrix and vectors
In the event that the GLER/router/PCE computes a non-viable
input/output link pair, the GLSR MAY via a slightly modified crank-
back mechanism, return the viable output links for the given input
link. The GLER/router/PCE may then incorporate this crank-
back/feedback data into a subsequent path computation. This avoids a
continuous series of identical mistakes by the PCE or GLER.
The advantage of this abstraction is it allows better visibly and
control of link viability while still abstracting the physical
topology. Wavelength-fixed links can be represented more accurately.
The disadvantages are that the detailed link matrix can be fairly
large since the matrix grows with the square of the number of links.
Also as the optical network fills the matrix becomes sparse which
implies that a sparse vector is the way to alleviate some of the
requirements for the information exchanged and stored. This scheme
still has many of the drawbacks mentioned in the previous section.
Every time a path is established the reachbility matrix must be
recomputed. Link to link costs and viability will change over time
as the network fills.
3.2.1 Scalability of an Abstract GLSR
The abstract model gives a good view of capability to a GLER. But it
does represent a lot of information. Potentially there is a lot of
information since it is the Square of all the inputs/wavelengths.
The size of the matrix is dimensioned by the number of wavelengths *
the bits per wavelength cost * the number of links squared * the
number of optical formats. With typical numbers this could be about
1Meg of raw data.
P. Ashwood-Smith July 2005 9
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
3.3 Full GMPLS topology
This section is a place holder for a view that would have all
detailed parameters stored on an optical node basis. The current
intention of this draft is to avoid specifying this level of detail.
This scheme would allow the GLER to specify paths accurately with a
high level of confident that the wavelength could be controlled.
However many other optical factors would have to be specified if the
path generated were to setup.
4. Path Computation Considerations
There are a number of different algorithms that will permit a
shortest path to be computed based on additional optical
constraints.
Depending on the abstract model chosen the path calculation will be
a loose hop of a certain granularity. Provisions must be made for
the fact that the topology is abstract and there are various ways to
represent this such that interfacing nodes can understand that
transitivity does not necessarily work. So if A can reach B and B
can reach C it does not necessarily follow that A can Reach C.
The portion of the path which traverses the pure photonic domain and
which is therefore logically contained within the abstract topology
is computed either by the optical controller or by other mechanisms
which have access to the full physics of the sub-domain. It is
therefore out of scope for this document at this time.
4.1. Diverse path pair computation.
Diverse paths may be computed such that they do not traverse the
same abstract-GLSRs using existing diverse pair mechanisms already
available in GMPLS. This limitation however will rule out some
possibly physically diverse paths that could traverse the same
abstract-GLSR however this finer grained diversity is for further
study.
4.2 Crankback Considerations
Regardless of the scheme chosen the requirement to support crankback
on path failure is desirable because there will be case where the
optical paths will not be able to be setup and the need to deal with
incorrect topology information will allow alternate paths to be
established.
This would be accomplished by adding TLVs to the RSVP-PathErr
message [GMPLS-RSVP] to help the originator of the Path message to
compute an ERO that will not block the originator of the Path
message MAY use this data for subsequent path computations, MAY pass
P. Ashwood-Smith July 2005 10
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
it to a PCE for subsequent path computations but must not advertise
this data via [OSPF-TE] or [IS-IS-TE].
When used, these should be part of the Error Code "Routing Error"
procedure but with a new Error Value of "ERO - non viable link
pair".
5. Security Considerations
The addition of new constraint data in the TE database is unlikely
to create additional security concerns. This is normal way of
extending the TE database and it is subject to the same security
concerns in GMPLS networks today.
The normal OSPF/IS-IS security mechanisms and network precautions
should prevent tampering with these attributes as they do any other
TE or route data.
6. IANA Considerations
TBD when the TLVs for the abstract topologies are designed.
7. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
8. References
[GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions in
Support of Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt
work in progress.
P. Ashwood-Smith July 2005 11
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
[L1VPN-FRMK] Tomonori, T., et. al., "Framework for Layer 1 Virtual
Private Networks", draft-takeda-l1vpn-framework-03.txt, work in
progress.
[L1VPN-GVPN] Ould-Brahim, H., Rekhter, Y., "GVPN Services:
Generalized VPN Services using BGP and GMPLS Toolkit",draft-
ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt, work in progress.
[OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[ISIS-TE] Smit, H., Li, T. Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE), RFC 3784,
June 2004.
[GMPLS-RSVP] Berger, L., (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[GMPLS-SIG] Berger, L. (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
9. Acknowledgements
The authors would like to thank: Hamid Ould-Brahim, Darek Skalecki
and Sandra Ballarte for their valuable comments.
10. Author's Addresses
Peter Ashwood-Smith
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 763 4534
Email: petera@nortel.com
Don Fedyk
Nortel Networks
600 Technology Park Drive
Billerica, MA, 01821
Phone: +1 978 288-3041
Email: dwfedyk@nortel.com
Vik Saxena
Comcast
Email:Vik_Saxena@cable.comcast.com
P. Ashwood-Smith July 2005 12
Internet Draft draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt
11. Disclaimer
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
P. Ashwood-Smith July 2005 13
