Internet DRAFT - 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 

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-
   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  
   The list of Internet-Draft Shadow Directories can be accessed at 
   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 
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 
   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 
   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 
   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 
   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 
   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 
   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-
   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 
   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 
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 
   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 
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 
   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- 
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 
   [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                   
   Don Fedyk 
   Nortel Networks 
   600 Technology Park Drive 
   Billerica, MA, 01821 
   Phone: +1 978 288-3041 
   Vik Saxena 

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      
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