[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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