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