[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
               
                  CCAMP Working Group                                     Kenji Kumaki
                                                                       KDDI Corporation
                                                                              Zafar Ali
                                                                          Cisco Systems
                                                                         Tomohiro Otani
                                                           KDDI R&D Laboratories, Inc.
                                                                         George Swallow
                                                                      Mallik Tatipamula
                                                                          Cisco Systems
                  Internet Draft
                  Category: BCP
                  Expires: July 2006                                      January 2006
               
               
               
                    Operational, Deployment and Interworking Considerations for GMPLS
                            draft-kumaki-ccamp-mpls-gmpls-interworking-02.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.
               
               Copyright Notice
               
                  Copyright (C) The Internet Society (2006). All Rights Reserved.
               
               
               
               
               K. Kumaki, et al.               Page 1
               
               [Page 1]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
               Abstract
               
                  In order to deploy GMPLS technology in the existing IP/MPLS networks,
                  various operation, deployment and interworking aspect of MPLS/GMPLS
                  needs to be addressed.
               
                  From the deployment perspective, GMPLS architecture document lists
                  [RFC3945] three different scenarios in which GMPLS technology can be
                  deployed: overlay, augmented and integrated. Reference [GMPLS-mig]
                  addresses the problem of migration from MPLS to GMPLS networks using
                  the integrated model. This draft addresses the same problem space for
                  augmented model and illustrates the applicability of augmented model
                  in deploying GMPLS technology in existing IP/MPLS networks.
               
               
                  Another very important aspect of MPLS/GMPLS interworking is ability
                  to effectively use GMPLS services in IP/MPLS networks. This includes
                  ability to specify GMPLS LSPs in signaling requests based on the type
                  of the setup desired, as well as considerations for the operation
                  aspects of using GMPLS LSPs.
               
               
                  In this draft, we highlight some deployment and MPLS/GMPLS
                  interworking requirements and propose solutions to address them. We
                  also highlight some operation aspects and the possible solution and
                  provide applicability statement for the available options.
               
               Conventions used in this document
               
                  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
                  document are to be interpreted as described in RFC 2119 [RFC2119].
               
               Routing Area ID Summary
               
                  (This section to be removed before publication.)
               
                  SUMMARY
               
                  This document addresses some MPLS/ GMPLS deployment, operational and
                  interworking aspects.
               
                  WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK?
               
                  This work fits in the context of MPLS/GMPLS deployment, operational
                  and interworking.
               
               
               K. Kumaki, et al.               Page 2
               
               [Page 2]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
                  WHY IS IT TARGETED AT THIS WG?
               
                  This document is targeted at ccamp as it addresses some MPLS/GMPLS
                  deployment, operational and interworking aspects.
               
                  RELATED REFERENCES
               
                  Please refer to the reference section.
               
               Table of Contents
               
                   1. Introduction..................................................4
                   2. Terminology...................................................5
                   3. MPLS/GMPLS Deployment,Operational and interworking requirements5
                   3.1 Software Upgrade Requirement.................................5
                   3.2 Use of GMPLS network resources in IP/MPLS networks...........6
                   3.3 Interworking of MPLS and GMPLS protection....................6
                   3.4 Separation of IP/MPLS domain and GMPLS domain................6
                   3.5 Failure recovery.............................................6
                   4. Augmented model...............................................6
                   4.1 Routing in Augmented Model...................................7
                   4.2 Failure Recovery in Augmented Model..........................7
                   4.3 Management in Augmented model................................8
                   4.4 GMPLS Deployment Considerations..............................8
                   4.5 Applicability of real/virtual FA-LSP.........................8
                   4.6 Applicability of FA Utilization..............................9
                   4.7 Bundling FA-LSP..............................................9
                   5. MPLS/GMPLS Interworking aspects...............................9
                   5.1 Static vs. signaling triggered dynamic FA-LSPs...............9
                   5.2 MPLS/GMPLS LSP Resource Affinity Mapping....................10
                   5.3 MPLS/GMPLS LSP Priority Mapping.............................10
                   5.4 Signaling Protected MPLS LSPs...............................11
                   6. Operational Considerations...................................12
                   6.1 Applicability of the Priority Management Options............12
                   6.2 Applicability of the Signaling Triggered Dynamic FA-LSP.....13
                   7. Backward Compatibility Note..................................13
                   8. Security Considerations......................................13
                   9. Intellectual Property Considerations.........................13
                   10.Acknowledgement..............................................14
                   11.Reference....................................................14
                   11.1 Normative Reference........................................14
                   11.2 Informative Reference......................................14
                   12.Author's Addresses...........................................15
                   13.Full Copyright Statement.....................................16
               
               
               
               
               K. Kumaki, et al.               Page 3
               
               [Page 3]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               1. Introduction
               
                  Introduction of GMPLS technology in existing IP/MPLS networks and
                  migration of IP/MPLS services to GMPLS core poses some new
                  requirements that do not exist while using point to point physical
                  links in the core network. One of the biggest challenges in today's
                  network is "how to deploy GMPLS technology" in a manner least impact
                  on the existing IP/MPLS networks. It is neither feasible nor desired
                  to upgrade all existing nodes to GMPLS technology. In fact, it is
                  required to minimize the impact of migration to GMPLS on the existing
                  IP/MPLS network. It is also desired to respect the administrative
                  boundaries between IP/MPLS and Optical domains.
               
                  There are several architectural alternatives including overlay,
                  integrated and augmented models proposed in GMPLS architecture
                  document [RFC3945]. The key difference among these models is how much
                  and what kind of network information can be shared between packet and
                  Optical domains. Peer model is suitable, where optical transport and
                  Internet/Intranet Service networks are operated by a single entity.
                  Currently, many service providers have traditionally built their
                  networks, where Optical transport and IP/MPLS service networks belong
                  to different operation, management, ownership. Most important thing
                  is that service providers wants to operate and manage their networks
                  independently, and deploy them without changing existing IP/MPLS
                  network topologies, protocols and scalability. Overlay model is
                  suitable for such scenario, however does not offer the benefits of
                  peer model approach for efficient resource utilization, optimal
                  routing and protection and restoration between IP/MPLS and Optical
                  networks. Augmented model is suitable in this scenario, where Optical
                  transport and IP/MPLS service networks administrated by different
                  entities and would like to maintain a separation between IP/MPLS and
                  Optical layers, at the same time, get the benefits of integrated
                  model approach.
               
                  Reference [GMPLS-mig] addresses the problem of migration from MPLS to
                  GMPLS networks using the integrated model. This draft addresses the
                  GMPLS deployment considerations using augmented model and illustrates
                  how it can be used in existing IP, MPLS and non-IP/MPLS networks. In
                  this regard, there are three different considerations taken into
                  account while comparing these approaches. They are: Deployment
                  considerations, routing aspects, and failure recovery considerations.
               
                  MPLS/GMPLS interworking is also an important aspect that needs to be
                  considered in deploying GMPLS technology in existing IP/MPLS networks.
                  MPLS/GMPLS interworking function refers to methods deployed for
                  mapping between MPLS LSPs and GMPLS LSPs. From a Packet Switching
                  Capable (PSC) network point of view, a router in the PSC network sees
               
               
               K. Kumaki, et al.               Page 4
               
               [Page 4]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
                  GMPLS LSP (signaled in non-PSC network) as a point-to-point link. How
                  effectively IP/MPLS networks can utilize these TE links (FA-LPSs)
                  created in GMPLS networks is an important aspect that needs to be
                  considered.
               
                  Resource affinity and Priority management are operational aspect that
                  must be considered in deploying GMPLS technology. Specifically, GMPLS
                  technology is equipped with features like resource affinity and
                  priority management, protection and restoration. These features have
                  some implications on how IP/MPLS networks can utilize forwarding
                  and/or routing adjacencies established on top of GMPLS networks.
                  Especially, these management can be a local decision.
                  In this draft, we highlight these implications/requirements and
                  propose solutions to address them. In this fashion this draft
                  complements [GMPLS-mig] draft, which formalizes the MPLS/GMPLS
                  interworking problem. However, [GMPLS-mig] draft does not address
                  MPLS/GMPLS interworking problems such as a mapping between protected
                  MPLS LSPs and protected GMPLS LSPs.
               
                  Feature richness of MPLS and GMPLS technology allows service
                  providers to use a set of options on how GMPLS services can be used
                  by IP/MPLS networks. However, there are some operational
                  considerations and pros and cons associated with the individual
                  options. This draft also highlights some operations considerations
                  associated with use of GMPLS services by IP/MPLS networks.
               
               2. Terminology
               
                  SP: Service provider
                  MPLS LSP setup request: MPLS rsvp path message
                  MPLS signaling request: MPLS rsvp path message
                  MPLS TE topology: MPLS TE database (TED)
               
               3. MPLS/GMPLS Deployment,Operational and interworking requirements
               
                  In this section, we highlight requirements that service providers
                  have in order to deploy GMPLS technology in existing IP/MPLS networks.
               
               3.1 Software Upgrade Requirement
               
                   Generally speaking, it is not practical to upgrade all IP/MPLS
                   routers to GMPLS capable routers in real SP networks due to a number
                   of reasons. Especially, in case of accommodating enterprise customer,
                   we do not allow IP/MPLS routers to upgrade GMPLS capable routers.
                   This means in the real IP/MPLS networks some routers would not be
                   upgraded to support GMPLS and some routers support would it.
               
               
               
               K. Kumaki, et al.               Page 5
               
               [Page 5]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               3.2 Use of GMPLS network resources in IP/MPLS networks
               
                   Most SPs have different networks for various services; their GMPLS
                   deployment plans are to have these service networks use a common
                   GMPLS controlled optical core. We need a way to make effective use
                   of GMPLS network resources (e.g. bandwidth) by the IP/MPLS service
                   networks.
               
               
               3.3 Interworking of MPLS and GMPLS protection
               
                   If MPLS LSPs are protected using MPLS FRR [RFC4090], when an FRR
                   protected packet LSP is signaled, we should be able to select
                   protected FA-LSPs from GMPLS network. In terms of MPLS protection,
                   MPLS path message can be included some flags in FAST REROUTE object
                   and SESSION_ATTRIBUTE object.
                   In terms of GMPLS protection, there are both signaling aspects
                   [RFC3471] [RFC3473] and routing aspects [GMPLS-routing].
                   Protected MPLS LSPs should be able to select GMPLS protection type
                   with the option.
               
               3.4 Separation of IP/MPLS domain and GMPLS domain
               
                   Most SPs have had different networks for every service, where
                   optical networks and IP/MPLS networks belong to different operation,
                   management, ownership. Most important thing is that SPs want to
                   operate and manage their networks independently, and deploy them
                   without changing existing IP/MPLS network topologies, protocols and
                   affecting scalability.
               
               3.5 Failure recovery
               
                   Failure in optical routing domain should not affect services in
                   IP/MPLS routing domain, and failure can be restored/repaired in
                   optical domain without impacting IP/MPLS domain and vice versa.
               
               4. Augmented model
               
                  Augmented Model is introduced in GMPLS Architecture document
                  [RFC3945]. It is a hybrid model between the full peer and overlay
                  models as shown in figure1. Border nodes at the edge of IP/MPLS
                  domain and optical domain receive routing information from the
                  optical devices (in optical domain) and nodes (in IP/MPLS domain).
                  Based on this information, border node keeps the optical and IP/MPLS
                  routing domain topology information in separate topology database. No
                  routing information from the router region is carried into the
                  optical region and vice versa.  These are quite useful aspects from
               
               
               K. Kumaki, et al.               Page 6
               
               [Page 6]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
                  MPLS/GMPLS deployment, operations as well as interworking
                  requirements.
               
               
                                         |        Optical Transport           |
                                         |            Network                 |
                        +--------+  +--------+     +-------+  +-------+    +--------+   +---------+
                        |        |  |        |     |       |  |       |    |        |   |         |
                        | IP/MPLS+--+ Border +--+--+ OXC1  +--+ OXC2  +-+--+ Border +---+ IP/MPLS |
                        | Service|  | Node   |     |       |  |       |    | Node   |   | Service |
                        | Network|  |        |     |       |  |       |    |        |   | Network |
                        +-----+--+  +---+----+     +-----+-+  +---+---+    +--------+   +---------+
               
                  Figure 1. Augmented Model
               
               4.1 Routing in Augmented Model
               
                  Augmented model maintains a separation between optical and routing
                  topologies; unlike integrated model approach, where topology
                  information is shared between IP/MPLS and Optical domains.
                  Nonetheless, as the border node has full knowledge of the optical
                  network, it can compute routes for GMPLS LSPs within the optical
                  domain. This allows augmented model to be more efficient in resource
                  utilization than overlay model, such that router and optical domain
                  resource can be optimized. At the same time, it can yield more
                  efficient use of resources, similar to the full peer model.  In the
                  full peer model, however, since all the devices in optical and
                  routing domains share the same topology and routing information with
                  same IGP instance, it requires all the devices within peer model to
                  be MPLS/GMPLS aware.
               
               4.2 Failure Recovery in Augmented Model
               
                  Both integrated model and augmented model offer a tighter
                  coordination between IP/MPLS and optical layers, which helps to
                  resolve uncorrelated failures. This is unlike overlay model, which
                  offers no coordination between optical and IP/MPLS layers;
                  consequently a single failure in one layer may trigger uncorrelated
                  failures in the other domain, which may complicate the fault handling.
               
                  Another important aspect in augmented model is failure transparency,
                  i.e., a failure in an optical network does not affect operations at a
                  router network and vice versa. Specifically, failure in the optical
                  domain does not affect services in routing (IP/MPLS) domain, and
                  failure can be restored/repaired in optical domain without impacting
                  IP/MPLS domain and vice versa. Where as in peer model, since optical
               
               
               
               K. Kumaki, et al.               Page 7
               
               [Page 7]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
                  and IP/MPLS domains share the same topology and routing information,
                  failure in optical domain is visible to IP/MPLS domain and vice versa.
               
               4.3 Management in Augmented model
               
                  Currently, many SPs have traditionally built their networks, where
                  Optical transport and IP/MPLS service networks belong to different
                  operation, management, ownership. In augmented model, each network
                  administrator can operate and manage his network independently
                  because this model maintains a complete separation between these
                  networks.
               
               
               4.4 GMPLS Deployment Considerations
               
                  In the integrated model, since all the devices in optical and routing
                  domains share the same topology and routing information with same IGP
                  instance, it requires all the devices within peer model to be
                  MPLS/GMPLS aware. Reference [GMPLS-mig] discusses various aspects of
                  migration from MPLS to GMPLS technology using integrated model.
               
                  In augmented model, as shown in figure 1, devices within optical and
                  its routing domains have no visibility into others topology and/or
                  routing information, except the border nodes. This will help
                  augmented model to accommodate both MPLS based or non-MPLS based
                  service networks connected to border nodes, as long as Border node in
                  augmented model can support GMPLS control plane.
               
                  One of the main advantages of the augmented model in the context of
                  GMPLS deployment is that it does not require existing IP/MPLS
                  networks to be GMPLS aware. Only border nodes need to be upgraded
                  with the GMPLS functionality. In this fashion, augmented model
                  renders itself for incremental deployment of the optical regions,
                  without requiring reconfiguration of existing areas/ASes, changing
                  operation of IGP and EGP or software upgrade of the existing IP/MPLS
                  service networks.
               
               4.5 Applicability of real/virtual FA-LSP
               
                  Real/Virtual FA-LSPs discussed in [GMPLS-mig] are equally applicable
                  to the integrated and augmented models. Specifically, in augmented
                  model, the border node can advertise virtual GMPLS FA-LSPs into
                  IP/MPLS networks and can establish the LSP statically or dynamically
                  on as needed basis. The only additional requirement posed by the
                  augmented model is to have at least one full routing adjacency over
                  the GMPLS LSP, such that TE topology exchange for the individual
                  service network can happen.
               
               
               K. Kumaki, et al.               Page 8
               
               [Page 8]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
               4.6 Applicability of FA Utilization
               
                  There are several possible schemes for determining how many FAs to
                  provision, when to enable the FAs, and whether to choose FAs of
                  virtual FAs as discussed in [GMPLS-mig] for integrated model. These
                  aspects of FA Utilization are equally applicable to augmented model,
                  with intelligence of FA Utilization implemented at the border node.
               
               4.7 Bundling FA-LSP
               
                  In augmented model, it is also possible to bundle GMPLS FA-LSPs at
                  the border nodes. Since IP/MPLS network will only see a bundled link
                  with TE or IGP attributes, operations on the bundled link, e.g.,
                  adding a new component link, failure of a component link, etc., are
                  completely transparent to the rest of the network.
               
               
               5. MPLS/GMPLS Interworking aspects
               
                  This section outlines some MPLS/GMPLS interworking aspects.
               
               5.1 Static vs. signaling triggered dynamic FA-LSPs
               
                  From signaling perspective, clearly there are two alternatives in
                  which setup for GMPLS tunnel can be triggered: Static (pre-
                  configured) and Dynamic (on-demand based on signaling setup request).
               
                  Decision to establish new Static GMPLS LSPs are made either by the
                  operator or automatically (e.g., using features like TE auto-mesh).
                  In either case, Static FA-LSP are established and advertised prior to
                  setup of MPLS LSPs using them in the ERO. In case of static FA-LSP,
                  if MPLS LSP setup request cannot be satisfied by existing Static FA-
                  LSPs, it is rejected.
               
                  Dynamic FA-LSP is triggered by MPLS LSP setup request for an MPLS LSP.
                  Please note that dynamic FA-LSPs can be virtual FAs from routing
                  perspective. In either case, LSP creation from signaling perspective
                  is triggered by the MPLS RSVP Path message received at a MPLS/GMPLS
                  border router.
               
                  In the case of Static or Virtual FA-LSPs, the FA may be specified in
                  an ERO encoded as strict ERO. In the case where FA-LSPs are dynamic
                  and are not advertised as virtual links in the MPLS TE topology, MPLS
                  signaling request contains a loose ERO, and GMPLS LSP selection is a
                  local decision at the border router. In the case of Static or Virtual
                  FA-LSPs, a signaling request may also be encoded as loose ERO.
               
               
               K. Kumaki, et al.               Page 9
               
               [Page 9]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
                  When the border router receives the signaling setup request and
                  determines that in order for it to expand the loose ERO content, it
                  needs to create GMPLS FA-LSP. Consequently, it signals a GMPLS LSP
                  respecting MPLS/GMPLS signaling interworking aspects discussed in
                  this sections. Once the GMPLS FA-LSP is fully established, the ERO
                  contents for the MPLS signaling setup request are expanded to use the
                  GMPLS LSP and signaling setup for the FA-LSP are carried in-band of
                  the GMPLS LSP. The GMPLS LSP can then also be advertised as an FA-LSP
                  in MPLS TE topology or an IGP adjacency can be brought up on the
                  GMPLS LSP.
               
               5.2 MPLS/GMPLS LSP Resource Affinity Mapping
               
                  In terms of signaling aspects, both MPLS and GMPLS LSPs are signaled
                  for specific resource class affinities [RFC3209], [RFC3473]. This can
                  be viewed as "colors". In terms of routing aspects, resource classes
                  are associated with links and advertised by routing protocol in
                  IP/MPLS domain [RFC3630] and GMPLS domain, respectively.
               
                  A real or virtual GMPLS FA-LSP or a full Routing Adjacency (RA) over
                  GMPLS LSP can be advertised as TE-links with resource class.
                  In this case, MPLS routers can select a GMPLS FA/RA that has a
                  specific color.
               
                  If MPLS signaling request contains a loose ERO, and GMPLS LSP
                  selection is a local decision at the border router. This is possible
                  for the cases when GMPLS LSP is not advertised into IP/MPLS networks.
                  In this case, any mapping combination may be defined manually and
                  dynamically based on some policies at the border router.
               
               
               
               5.3 MPLS/GMPLS LSP Priority Mapping
               
                  In terms of signaling aspects, both MPLS and GMPLS LSPs are signaled
                  for specific setup and hold priority [RFC3209], [RFC3473], based on
                  the importance of traffic carried over them. For proper operation of
                  the network, it is desirable to create/use GMPLS LSPs of specified
                  setup and hold priority, based on the setup and hold priority of the
                  MPLS LSPs using them. In terms of routing aspects, unreserved
                  bandwidth sub-TLV is used for the amount of bandwidth not yet
                  reserved at each of the eight priority levels in MPLS domain
                  [RFC3630] and max lsp bandwidth at priority 0-7 in interface
                  switching capability descriptor sub-TLV is used for the amount of
                  bandwidth that can be reserved at each of the eight priority levels
                  in GMPLS domain [GMPLS-ospf-routing].
               
               
               K. Kumaki, et al.              Page 10
               
               [Page 10]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
                  In an MPLS/GMPLS interworking, if a GMPLS LSP is advertised into
                  IP/MPLS networks as an FA/RA, an LSR in the packet network can see it
                  a TE-link with unreserved bandwidth as advertised by the border
                  router. In this case, MPLS routers can select links that meet a
                  bandwidth depending on a priority level.
               
                  If MPLS signaling request contains a loose ERO, the GMPLS LSP
                  selection is a local decision at the border router. This is possible
                  in the case where GMPLS LSP is not advertised as an FA into IP/MPLS
                  networks.
                  In this case, following approaches are possible for mapping setup and
                  hold priority of MPLS LSPs to GMPLS FA-LSPs. These mapping functions
                  can be applied, either manually or dynamically, depending on some
                  policies at the border router.
               
               
                  1) Exact Match: In this case setup and hold priority of the GMPLS
                     FA-LSP is same as setup and hold priority of MPLS LSP using it.
                     In other words, GMPLS LSP Priority set = MPLS LSP Priority set.
               
                  2) Better Priority: In this case GMPLS FA-LSP can be of setup and
                     hold priority equal better than the MPLS LSP using it. In other
                     words, GMPLS LSP Priority set <= MPLS LSP Priority set.
               
                  3) Dynamic Priority for GMPLS LSP: In this case priority of GMPLS
                     LSP is dynamically changed based on priority of the MPLS LSPs
                     using it. In other words, GMPLS LSP Priority set = min (MPLS LSP
                     Priority set).
               
                  4) Any to Any Mapping Matrix: Based on some policies, it is possible
                     to have an any-to-any mapping for MPLS/GMPLS priority mapping at
                     the MPLS/GMPLS border router.
               
                  5) No Priority Management in GMPLS core: In this simple minded
                     approach all GMPLS LSPs can be establish with setup and hold
                     priority of "0", i.e., the GMPLS LSPs are already set as better
                     match. In this case, priority management is handled purely at
                     MPLS layer, with GMPLS network providing L1 connectivity without
                     priority management.
               
               5.4 Signaling Protected MPLS LSPs
               
                  When MPLS LSPs are protected using MPLS-FRR mechanism [RFC4090] and
                  it may be desired to signal MPLS LSP such that it uses protected
                  GMPLS tunnel FA-LSPs. In this section we discuss MPLS/GMPLS
                  interworking aspect for protected MPLS LSPs.
               
               
               K. Kumaki, et al.              Page 11
               
               [Page 11]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
                  In the case of loose ERO, where selection of GMPLS FA-LSP is a left
                  for the border nodes and "One-to-One backup desired" or "facility
                  backup desired" flag of the FAST REROUTE object, "Local protection
                  desired" and/or "bandwidth protection desired" and/or "node
                  protection desired" flag of the SESSION_ATTRIBUTE object is set, the
                  border router SHOULD try to map the signaling setup request to a
                  GMPLS LSP which is protected within GMPLS domain. However, in the
                  case of strict ERO, the selection of GMPLS FA-LSP is based on the
                  contents of the ERO and these flags are ignored.
               
                  When a GMPLS LSP is advertised as FA or RA in MPLS network,
                  Protection Capabilities attribute of the Link Protection Type is a
                  sub-TLV of the Link TLV can be used for selecting GMPLS LSP of
                  desired protection capability.
               
               6. Operational Considerations
               
                  In this section, we discuss some operational considerations and pros
                  and cons associated with the individual options listed in Section 5.3.
               
               6.1 Applicability of the Priority Management Options
               
                  In section 5.3, various options from exact match to no priority
                  management in GMPLS network are discussed. This section provides an
                  applicability of these options.
               
                  The benefit of Priority Management in GMPLS Core comes at the cost of
                  bandwidth fragmentation. E.g., in simplest approach of exact match,
                  we need at least as many GMPLS LSPs, as there are priority
                  combination in the network, while the other extreme of no priority
                  management in GMPLS network does allow full aggregation of MPLS
                  traffic on GMPLS FAs, i.e. avoids bandwidth fragmentation. If IGP
                  adjacency is to be established over the GMPLS LSPs, having more GMPLS
                  LSP leads to more links in the IGP/IP topology. The same is true of
                  MPLS TE topology with the exception that FA-LSPs can be bundled to
                  avoid flooding of multiple TE links.
               
                  With priority management within GMPLS network, there is a danger of
                  creating oscillations in the IP/MPLS network using GMPLS. This is
                  because when a new FA-LSP is established based on a local routing
                  decision made at the border router; we can have undesirable
                  preemption affecting MPLS LSPs carried over the GMPLS LSP that is
                  being preempted. This can have cascading affect leading to
                  oscillations on the operation of MPLS traffic.
               
               
               
               
               K. Kumaki, et al.              Page 12
               
               [Page 12]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               6.2 Applicability of the Signaling Triggered Dynamic FA-LSP
               
                  In this section, we discussed applicability of static vs. dynamic FA-
                  LSPs. It is important to realize that we can have FA-LSPs that are
                  created dynamically based on triggers like configuration, link
                  utilization level, etc. However, in the context of this document,
                  such FA-LSPs are considered as static FAs. In this document, the term
                  dynamic FA-LSPs are used for FA-LSPs that are triggered by RSVP Path
                  message for MPLS LSP.
               
                  Signaling triggered dynamic FA-LSPs are addressing a problem space
                  where traffic pattern cannot be predicted or objective is to optimize
                  operations of the network based on actually signaled request rather
                  than predicted use of the network resource (i.e., off-line traffic
                  engineering).
               
                  The problem with the use of signaling triggered dynamic FA-LSPs is
                  that we loose ability to better aggregate the traffic request at the
                  border routers. This leads to potential cases of bandwidth
                  fragmentation inside GMPLS core, which has disadvantages discussed in
                  Section 6.1. Furthermore, signaling triggered dynamic FA-LSPs coupled
                  with preemption can lead to oscillations in the operation of the
                  network. This is because when a new FA-LSP is dynamically established
                  based on a local routing decision made at the border router; we can
                  have undesirable preemption affecting MPLS LSPs carried over the
                  GMPLS LSP that is being preempted. This can have cascading affect
                  leading to oscillations on the operation of MPLS traffic.
               
               
               7. Backward Compatibility Note
               
                  The procedure presented in this document is backward compatible with
                  [RFC3630], [RFC3784], [RFC3209] and [RFC3473].
               
               8. Security Considerations
               
                  This document does not introduce new security issues.
               
               9. 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
               
               
               
               K. Kumaki, et al.              Page 13
               
               [Page 13]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
                  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.
               
               10.Acknowledgement
               
                  The author would like to express the thanks to Arthi Ayyangar for
                  helpful comments and feedback.
               
               11.Reference
               
               11.1 Normative Reference
               
                  [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,
                  RFC 3209, December 2001.
               
                  [RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering
                  (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
               
                  [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
                  RFC 2119, S. Bradner, March 1997.
               
                  [GMPLS-mig] "IP/MPLS - GMPLS interworking in support of IP/MPLS to
                  GMPLS migration", draft-oki-ccamp-gmpls-ip-interworking-05.txt, D.
                  Brungard, et al, February 2005.
               
                  [RFC3945] "Generalized Multi-Protocol Label Switching (GMPLS)
                  Architecture",RFC 3945, E. Mannie,October 2004.
               
               
               11.2 Informative Reference
               
                  [GMPLS-routing] "Routing Extensions in Support of Generalized Multi-
                  Protocol Label Switching", draft-ietf-ccamp-gmpls-routing-09.txt
                  (work in progress), October 2003.
               
               
               K. Kumaki, et al.              Page 14
               
               [Page 14]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
                  [GMPLS-ospf-routing] "OSPF Extensions in Support of Generalized
                  Multi-Protocol Label Switching", draft-ietf-ccamp-ospf-gmpls-
                  extensions-12.txt (work in progress), October 2003.
               
                  [RFC2205] "Resource Reservation Protocol (RSVP) - Version 1,
                     Functional Specification", RFC 2205, Braden, et al, September 1997.
               
                  [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS)
                     Signaling Functional Description", RFC 3471, L. Berger, et al,
                     January 2003.
               
                  [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
                     Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-
                     TE) Extensions", RFC 3473, L. Berger, et al, January 2003.
               
                   [RFC4090] "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC
                   4090, Pan, et al, May 2005.
               
               
               12.Author's Addresses
               
                  Kenji Kumaki
                  KDDI Corporation
                  Garden Air Tower
                  Iidabashi, Chiyoda-ku,
                  Tokyo 102-8460, JAPAN
                  E-mail : ke-kumaki@kddi.com
               
                  Zafar Ali
                  Cisco systems, Inc.,
                  2000 Innovation Drive        Phone: 613 254 3498
                  Kanata, Ontario              Email: zali@cisco.com
                  Canada K2K 3E8
               
                  Tomohiro Otani
                  KDDI R&D Laboratories, Inc.
                  2-1-15 Ohara Kamifukuoka     Phone:  +81-49-278-7357
                  Saitama, 356-8502. Japan     Email:  otani@kddilabs.jp
               
                  George Swallow
                  Cisco Systems, Inc.
                  1414 Massachusetts Ave,
                  Boxborough, MA 01719
                  Phone:  +1 978 936 1398
                  Email:  swallow@cisco.com
               
               
               K. Kumaki, et al.              Page 15
               
               [Page 15]


                        draft-kumaki-ccamp-mpls-gmpls-interworking-02.txt  January 2006
               
               
               
                  Mallik Tatipamula
                  Cisco systems, Inc.,
                  170 W. Tasman Drive
                  San Jose, CA 95134           Phone: 408 525 4568
                  USA.                         Email: mallikt@cisco.com
               
               13.Full Copyright Statement
               
                  Copyright (C) The Internet Society (2006).
               
                  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.
               
                  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.
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               K. Kumaki, et al.              Page 16
               
               [Page 16]