[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk

               Network Working Group                               Kohei Shiomoto(NTT)
               Internet Draft                           Dimitri Papadimitriou(Alcatel)
               Proposed Category: Informational     Jean-Louis Le Roux(France Telecom)
               Expires: August 2006                            Deborah Brungard (AT&T)
                                                                   Kenji Kumaki (KDDI)
                                                                         Eiji Oki(NTT)
                                                                     Ichiro Inoue(NTT)
                                                                 Tomohiro Otani (KDDI)
                                                                         February 2006
               
                    Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to
                                             GMPLS migration
               
                          draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.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
               
                  The migration from Multiprotocol Label Switching (MPLS) to
                  Generalized MPLS (GMPLS) is the process of evolving an MPLS traffic
                  engineered (TE) control plane to a GMPLS control plane. An
                  appropriate migration strategy can be selected based on various
                  factors including the service provider's network deployment plan,
                  customer demand, available network equipment implementation,
                  operational policy, etc.
                  In the course of migration, several interworking cases may exist
                  where MPLS and GMPLS devices or networks must coexist. During the
                  migration process, standard interworking functions are needed to
               
                                         Expires June 2006                     [Page 1]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  allow graceful deployment of GMPLS technologies while keeping
                  existing IP/MPLS networks unaffected.
                  Since GMPLS signaling and routing protocols are different from the
                  MPLS control protocols, in order for MPLS and GMPLS to interwork, we
                  need mechanisms to compensate for the differences between MPLS and
                  GMPLS. This document provides a landscape of techniques, practices
                  and an overview of interworking between MPLS and GMPLS in support of
                  IP/MPLS to GMPLS migration, which is also beneficial for graceful
                  deployment of GMPLS technologies into existing IP/MPLS networks. We
                  discuss issues, models, migration scenarios, operation, and
                  requirements.
               
               
               Table of Contents
               
                  1. Introduction.....................................................3
                  2. Conventions Used in This Document................................4
                  3. Motivations for Migration........................................4
                  4. MPLS to GMPLS migration..........................................5
                  4.1. Migration models...............................................5
                  4.1.1. Island model.................................................5
                  4.1.2. Integrated model.............................................6
                  4.1.3. Phased model.................................................7
                  4.2. Migration strategies...........................................7
                  5. Island model interworking cases..................................8
                  5.1. MPLS-GMPLS(PSC)-MPLS Islands...................................8
                  5.2. MPLS-GMPLS(non-PSC)-MPLS Islands...............................9
                  5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands.............................9
                  5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands.....................9
                  5.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands....................9
                  6. Interworking issues between MPLS and GMPLS......................10
                  6.1. Signaling.....................................................10
                  6.1.1. GMPLS specific RSVP objects and Messages....................10
                  6.1.1.1 Direct interworking........................................11
                  6.1.2. Bidirectional LSP...........................................13
                  6.1.3. Failure recovery............................................13
                  6.2. Routing.......................................................13
                  6.2.1. Interworking of Routing Protocols...........................14
                  6.2.2. Mapping of Routing Protocols................................14
                  6.3. Layered Networks..............................................15
                  6.3.1. Peer Model..................................................16
                  6.3.2. Overlay Model...............................................17
                  6.3.3. Augmented Model.............................................17
                  7. Manageability Considerations....................................18
                  7.1. Control of Function and Policy................................18
                  7.2. Information and Data Models...................................18
                  7.3. Liveness Detection and Monitoring.............................19
                  7.4. Verifying Correct Operation...................................19
               
                                         Expires June 2006                [Page 2]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  7.5. Requirements on Other Protocols and Functional Components.....19
                  7.6. Impact on Network Operation...................................19
                  7.7. Other Considerations..........................................20
                  8. Security Considerations.........................................20
                  9. IANA Considerations.............................................20
                  10. Full Copyright Statement.......................................21
                  11. Intellectual Property..........................................21
                  12. Acknowledgements...............................................21
                  13. Authors' Addresses.............................................22
                  14. References.....................................................23
                  14.1. Normative References.........................................23
                  14.2. Informative References.......................................23
               
               
               1. Introduction
               
                  MPLS to GMPLS migration is the process of evolving an MPLS-TE-based
                  control plane to a GMPLS-based control plane.
               
                  There are several motivations for such migration and they focus
                  mainly on the desire to take advantage of new features and functions
                  that have been added to the GMPLS protocols but which are not present
                  in MPLS.
               
                  Although an appropriate migration strategy can be selected based on
                  various factors including the service provider's network deployment
                  plan, customer demand, available network equipment implementation,
                  operational policy, etc, the smooth transition mechanism should be
                  investigated from the consistent operation of GMPLS networks, while
                  less impacting the operation of existing MPLS networks.
               
                  In the course of migration, several interworking cases may arise
                  where MPLS and GMPLS devices or networks must coexist. Such cases may
                  occur as parts of the network are converted from MPLS protocols to
                  GMPLS protocols, or may arise if a lower layer network is made GMPLS-
                  capable (from having no MPLS or GMPLS control plane) in advance of
                  the migration of the higher layer network.
               
                  This document examines the interworking scenarios that arise during
                  migration, and examines the implications for network deployments and
                  for protocol usage. Since GMPLS signaling and routing protocols are
                  different from the MPLS control protocols, interworking between MPLS
                  and GMPLS networks or network elements needs mechanisms to compensate
                  for the differences. This document provides a framework for MPLS and
                  GMPLS interworking in support of migration from IP/MPLS to GMPLS by
                  discussing issues, models, migration scenarios, operation and
                  requirements. Solutions for interworking MPLS and GMPLS will be
                  developed in companion documents.
               
                                         Expires June 2006                [Page 3]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
               
                  Note that both MPLS and GMPLS protocols can co-exist as "ships in the
                  night" without any interworking issue. This document addresses
                  interworking to allow migration from MPLS to GMPLS. We should also
                  note that, in this document, a MPLS control plane means a MPLS-TE
                  control plane (RSVP-TE [RFC3209], IGP-TE [RFC3630] [RFC3784]), and
                  not a LDP-based control plane [RFC3036]. This document does not
                  address the migration from LDP controlled MPLS networks to G/MPLS
                  RSVP-TE at this moment, but may consider it in the future version.
               
               
               2. 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].
               
                  In the rest of this document, the term GMPLS includes both packet
                  switch capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS" or
                  "non-PSC GMPLS" is explicitly used.
               
                  The reader is assumed to be familiar with the terminology introduced
                  in [RFC3495].
               
               
               3. Motivations for Migration
               
                  Motivations for migration will vary for different service providers.
                  This section is only presented to provide background so that the
                  migration discussions may be seen in the context. Sections 4 and 5
                  illustrate the migration models and processes with possible examples.
               
                  Migration of an MPLS capable LSR to include GMPLS capabilities may be
                  performed for one or more reasons:
               
                  - To add all GMPLS capabilities to an existing MPLS PSC network.
                  - To add a GMPLS network without sacrificing the existing MPLS PSC
                  LSR implementation.
                  - To pick up specific GMPLS features and operate them within an MPLS
                     PSC network.
                  - To allow MPLS capable LSRs to interoperate with new LSRs that only
                     support GMPLS.
                  - To integrate multiple networks managed by separate administrative
                  organizations, which independently utilize MPLS or GMPLS.
                  - To build integrated PSC and non-PSC networks where the non-PSC
                     networks can only be controlled by GMPLS since MPLS does not
                     operate in non-PSC networks.
               
               
                                         Expires June 2006                [Page 4]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
               
               4. MPLS to GMPLS migration
               
               4.1. Migration models
               
                  MPLS to GMPLS migration is a process of evolving an MPLS-TE-based
                  control plane to a GMPLS-based control plane. Three migration models
                  are considered as described below. Practically speaking, multiple
                  migration models may be deployed at the same time.
               
               4.1.1. Island model
               
                  In the island model, "islands" of network nodes operating one
                  protocol exist within a "sea" of nodes using the other protocol.
               
                  The most obvious example is to consider an island of GMPLS-capable
                  nodes which is introduced into a legacy MPLS network. Such an island
                  might be composed of newly added GMPLS network nodes, or might arise
                  from the upgrade of existing nodes that previously operated MPLS
                  protocols.
               
                  The opposite is also quite possible. That is, there is a possibility
                  that an island happens to be MPLS-capable within a GMPLS sea. Such a
                  situation might arise in the later stages of migration, when all but
                  a few islands of MPLS-capable nodes have been upgraded to GMPLS.
               
                  It is also possible that a lower-layer, manually-provisioned network
                  (for example, a TDM network) supports an MPLS PSC network. During the
                  process of migrating from both networks to GMPLS, the situation might
                  arise where the lower-layer network has been migrated and operates
                  GMPLS, but the packet network still operates MPLS. This would appear
                  as a GMPLS island within an MPLS sea.
               
                  Lastly, it is possible to consider individual nodes as islands. That
                  is, it would be possible to upgrade or insert an individual GMPLS-
                  capable node within an MPLS network, and to treat that GMPLS node as
                  an island.
               
                  Over time, collections of MPLS devices are replaced or upgraded to
                  create new GMPLS islands or to extend existing ones, and distinct
                  GMPLS islands may be joined together until the whole network is
                  GMPLS-capable.
               
                  From a migration/interworking point of view, we need to examine how
                  these islands are positioned and how LSPs run between the islands.
                  Four categories of interworking scenarios are considered: (1) MPLS-
                  GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS.
                  In each case, the interworking behavior is examined based on whether
               
                                         Expires June 2006                [Page 5]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  the GMPLS islands are PSC or non-PSC. These scenarios are considered
                  further in section 5.
               
                  Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS
                  interworking. The model consists of a transit GMPLS island in an MPLS
                  sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and
                  G6) are referred to as "island border nodes". If the GMPLS island was
                  non-PSC, all nodes except the island border nodes in the GMPLS-based
                  transit island (G3 and G4) would be non-PSC devices, i.e., optical
                  equipment (TDM, LSC, and FSC).
               
                  ................. .............................. ..................
                  :      MPLS      : :      GMPLS                : :     MPLS       :
                  :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
                  :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
                  :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
                  :      ________/ : :  ________/  |   ________/ : :  ________/     :
                  :     /          : : /           |  /          : : /              :
                  :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
                  :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
                  :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
                  :................: :...........................: :................:
               
                     |<-------------------------------------------------------->|
                                                    e2e LSP
               
                  Figure 1: Example of the island model for MPLS-GMPLS-MPLS
                  interworking.
               
               4.1.2. Integrated model
               
                  The second model involves a more integrated migration strategy. New
                  devices that are capable of operating both MPLS and GMPLS protocols
                  are introduced into the MPLS network. We should note that the GMPLS-
                  capable device may not support a full set of MPLS functionalities.
                  For example, a GMPLS-capable device may support protection and
                  restoration mechanisms in [E2E-recovery, SEGMENT-recovery] but may
                  not support the fast reroute mechanism defined in [RFC4090]. This
                  fact highlights the difference between the island and the integrated
                  models. That is to say, in the island model, a GMPLS node does not
                  support MPLS features (signaling code points, FRR, etc), while in the
                  integrated model, the new device supports both MPLS and GMPLS
                  features.
               
                  Further, existing MPLS devices will be upgraded to support both MPLS
                  and GMPLS. The network continues to operate providing MPLS services,
                  but where the service can be provided using only GMPLS functionality,
                  it may be routed accordingly over only such MPLS-GMPLS-capable
               
                                         Expires June 2006                [Page 6]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  devices and achieve a higher level of functionality by utilizing
                  GMPLS features. Once all devices in the network are GMPLS-capable,
                  the MPLS specific protocol elements (signaling code points, FRR, etc)
                  may be turned off, and no new devices need to support these elements.
               
                  In this second model, the questions to be addressed concern the co-
                  existence of the two protocol sets within the network. Actual
                  interworking is not a concern.
               
                  The integrated migration model results in a single network in which
                  both MPLS-capable and MPLS-GMPLS-capable LSRs co-exist. Some LSRs
                  will be capable of only MPLS, and some of both MPLS and GMPLS. The
                  migration strategy here involves introducing MPLS-GMPLS-capable LSRs
                  into an existing MPLS-capable network (i.e. upgrading MPLS LSRS)
                  until all LSRs are MPLS-GMPLS-capable at which time all MPLS
                  functionalities can be disabled, and there are no interworking issues
                  in the data plane. In the control plane, the migration issues concern
                  the separation of MPLS and GMPLS protocols, and the choice of routes
                  that may be signaled with only one protocol.
               
               4.1.3. Phased model
               
                  The phased model introduces GMPLS features and protocol elements into
                  an MPLS network one by one. For example, some object or sub-object
                  (such as the ERO label sub-object, [RFC3473]) might be introduced
                  into the signaling used by LSRs that are otherwise MPLS-capable. This
                  would produce a kind of hybrid LSR.
               
                  This approach may appear simpler to implement as one is able to
                  quickly and easily pick up key new functions without needing to
                  upgrade the whole protocol implementation.
               
                  The interoperability concerns (e.g. LABEL REQUEST object [RFC3473]
                  and LABEL object [RFC3209], for RSVP-TE signaling) though are
                  exacerbated by this migration model, unless all LSRs in the network
                  are updated simultaneously.
               
                  Interworking between a hybrid LSR and an unchanged MPLS LSR would put
                  the hybrid in the role of a GMPLS LSR as described in the previous
                  sections, while interworking between a hybrid LSR and a GMPLS LSR
                  puts the hybrid in the role of an MPLS LSR. The potential for
                  different hybrids within the network will complicate matters
                  considerably. Thus, this piecemeal migration from MPLS to GMPLS is
                  NOT RECOMMENDED.
               
               4.2. Migration strategies
               
               
               
                                         Expires June 2006                [Page 7]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  An appropriate migration strategy is selected based on various
                  factors including the service provider's network deployment plan,
                  customer demand, available network equipment, operational policy, etc.
               
                  For PSC networks, the migration strategy involves the selection
                  between the models described in the previous section. The choice will
                  depend upon the final objective (full GMPLS capability or partial
                  upgrade to include specific GMPLS features or no change of existing
                  IP/MPLS networks), and upon the immediate objectives (full, phased,
                  or staged upgrade).
               
                  For PSC networks supported by non-PSC networks, two basic migration
                  strategies can be considered. In the first strategy, the non-PSC
                  network is made GMPLS-capable first and then the PSC network is
                  migrated to GMPLS. This might arise when, in order to expand the
                  network capacity, GMPLS-based non-PSC sub-networks are introduced
                  into or underneath the legacy MPLS-based networks. Subsequently, the
                  legacy MPLS-based PSC network is migrated to be GMPLS-capable as
                  described in the previous paragraph. Finally the entire network,
                  including both PSC and non-PSC nodes, may be controlled by GMPLS.
               
                  The second strategy for PSC and non-PSC networks is to migrate from
                  the PSC network to GMPLS first and then enable GMPLS within the non-
                  PSC network. The PSC network is migrated as described before, and
                  when the entire PSC network is completely converted to GMPLS, GMPLS-
                  based non-PSC devices and networks may be introduced without any
                  issues of interworking between MPLS and GMPLS.
               
                  These migration strategies and the migration models described in the
                  previous section are not necessarily mutually exclusive. Mixtures of
                  all strategies and models could be applied. The migration models and
                  strategies selected will give rise to one or more of the interworking
                  cases described in the following section.
               
               
               5. Island model interworking cases
               
               5.1. MPLS-GMPLS(PSC)-MPLS Islands
               
                  The migration of an MPLS-based packet network to become a GMPLS
                  (PSC)-based network may be performed to provide GMPLS-based advanced
                  features in the network, or to facilitate interworking with a GMPLS-
                  based optical core network.
               
                  The migration may give rise to islands of GMPLS support within a sea
                  of MPLS nodes such that an end-to-end LSP begins and ends on MPLS-
                  capable LSRs. The GMPLS PSC island may be used to "hide" islands of
                  GMPLS non-PSC functionality that are completely contained within the
               
                                         Expires June 2006                [Page 8]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  GMPLS PSC islands. This would protect the MPLS LSRs from having to be
                  aware of non-PSC technologies.
               
               5.2. MPLS-GMPLS(non-PSC)-MPLS Islands
               
                  The introduction of a GMPLS-based controlled optical core network to
                  increase the capacity of a MPLS packet network is an example that may
                  give rise to this scenario. Until the MPLS network is upgraded to be
                  GMPLS-capable, the MPLS and GMPLS networks must interwork. The
                  interworking challenges may be reduced by wrapping the non-PSC GMPLS
                  island entirely within a GMPLS PSC island as described in the
                  previous section.
               
               5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands
               
                  This case might arise as the result of installing new GMPLS-capable
                  islands around a legacy MPLS network, or as the result of controlled
                  migration of some islands to become GMPLS-capable.
               
               5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands
               
                  This case is out of scope for this document. Since the MPLS island is
                  necessarily packet capable (i.e. PSC), this scenario requires that
                  non-PSC LSPs are carried across a PSC network. Such a situation does
                  not arise through simple control plane migration, although the
                  interworking scenario might occur for other reasons, and be supported,
                  for example, by pseudo wires.
               
               5.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands
               
                  These cases are likely to arise where the migration strategy is not
                  based on a core infrastructure, but has edge nodes (ingress or
                  egress) located in islands of different capabilities.
               
                  In this case, an LSP starts or ends in a GMPLS (PSC) island and
                  correspondingly ends or starts in an MPLS island. Some signaling and
                  routing conversion is required on island border LSRs. Figure 2 shows
                  the reference model for this migration scenario. Head-end and tail-
                  end LSR are in distinct control plane clouds.
               
                  Since both islands are PSC there is no data plane conversion at the
                  island boundaries. However, from a control plane point of view this
                  model may prove challenging because the protocols must share or
                  convert information between the islands rather than tunnel it across
                  an island.
               
                       ............................. .............................
                       :            MPLS           : :    GMPLS (PSC)            :
               
                                         Expires June 2006                [Page 9]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                       :+---+        +---+        +---+        +---+        +---+:
                       :|R1 |__      |R11|___     |G1 |________|G3 |________|G5 |:
                       :+---+        +---+        +---+        +-+-+        +---+:
                       :      _      _____ _     / : :________/  |  _______/     :
                       :     /                     : : /         |  /            :
                       :+---+        +---+        +---+        +-+-+        +---+:
                       :|R2 |__      |R21|___     |G2 |________|G4 |________|G6 |:
                       :+---+        +---+        +---+        +---+        +---+:
                       :...........................: :...........................:
               
                         |<-------------------------------------------------->|
                                            e2e LSP
               
                                 Figure 2: GMPLS-MPLS interworking model.
               
                  It is also important to underline that this scenario is also impacted
                  by the directionality of the LSP, and the direction in which the LSP
                  is established. Indeed, a unidirectional packet LSP from R1 to G5 is
                  more easily accommodated at G1 than a bidirectional PSC LSP from G5
                  to R1.
               
               
               6. Interworking issues between MPLS and GMPLS
               
                  As described in the previous sections, interworking between MPLS and
                  GMPLS may form an essential part of a migration and deployment
                  strategy. This section sets out some of the alternatives for
                  achieving interworking between MPLS and GMPLS, and points out some of
                  the issues that need to be addressed if the alternatives are adopted.
                  This document does not describe solutions to these issues.
               
                  Note that it is possible to consider upgrading the routing and
                  signaling capabilities of LSRs from MPLS to GMPLS separately.
               
               6.1. Signaling
               
                  Signaling protocols are used to establish LSPs and are the principal
                  concern for interworking. This section outlines some of the issues
                  that may arise when MPLS and GMPLS signaling interworking is
                  attempted. Solutions to these issues will be described in separate
                  documents, but possibly rely on tunneling techniques (as described
                  above) or message mapping.
               
               6.1.1. GMPLS specific RSVP objects and Messages
               
                  GMPLS RSVP-TE signaling ([RFC3473]) introduces new RSVP-TE objects,
                  and their associated procedures, that are not processed/generated by
                  MPLS LSRs. Clearly an MPLS LSR cannot be expected to originate LSPs
               
                                         Expires June 2006               [Page 10]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  that use these objects and will, therefore, not have access to the
                  additional GMPLS functions. However, the new RSVP-TE objects listed
                  below need to be handled in interworking scenarios where the LSP
                  ingress and/or egress is GMPLS-capable, and MPLS LSRs are required to
                  process the signaling messages:
                   o The (Generalized) Label Request object (new C-Type), used to
                     identify the LSP encoding type, the switching type and the
                     generalized protocol ID (G-PID) associated with the LSP.
                   o The (Generalized) Label object (new C-Type)
                   o The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID
                     ERO/RRO subobjects that handle the Control plane/Data plane
                     separation in GMPLS network.
                   o The Suggested Label Object, used to reduce LSP setup delays.
                   o The Label Set Object, used to restrict label allocation to a set
                     of labels, (particularly useful for wavelength conversion
                     incapable nodes)
                   o The Upstream Label Object, used for bidirectional LSP setup
                   o The Restart Cap object, used for graceful restart.
                   o The Admin Status object, used for LSP administration, and
                     particularly for graceful LSP teardown.
                   o The Recovery Label object used for Graceful Restart
                   o The Notify Request object used to solicit notification of errors
                     and events.
                  o The Protection and Association objects used for LSP recovery
               
                  Future GMPLS extensions are likely to add further new objects.
               
                  Some of these objects can be passed transparently by MPLS LSRs to
                  carry them across MPLS islands because their C-Nums are of the form
                  11bbbbbb, but others would cause an MPLS LSR to reject the message
                  that carries them because their C-Nums are of the form 0bbbbbbb.
               
                  Even when objects are inherited from MPLS by GMPLS they can be
                  expected to cause problems. For example, the Label object in GMPLS
                  uses a new C-Type to indicate 'Generalized Label'. This C-Type is
                  unknown to MPLS LSRs that will reject any message carrying it.
               
                  GMPLS also introduces new message flags and fields (including new
                  sub-objects and TLVs) that will have no meaning to MPLS LSRs. This
                  data will normally be forwarded untouched by transit MPLS LSRs, but
                  they cannot be expected to act on it.
               
                  Also GMPLS introduces two new messages, the Notify message, and the
                  RecoveryPath message that are not supported by MPLS nodes.
               
               6.1.1.1 Direct interworking
               
               
               
                                         Expires June 2006               [Page 11]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  A possible solution is to allow direct signaling between MPLS and
                  GMPLS LSRs. However, a fundamental issue is that MPLS and GMPLS use
                  incompatible code points (C-Types) to request labels (LABEL_REQUEST
                  and GENERALIZED_LABEL_REQUEST) and to signal labels (LABEL and
                  GENERALIZED LABEL).
               
                  Note, however, that the Phased Model may offer a solution that
                  resembles signaling interworking. In this approach LSRs are upgraded
                  to support some GMPLS features but continue to use MPLS code points.
               
                  MPLS LSPs may be established across an island of enhanced signaling
                  capabilities, where some GMPLS features have been added to MPLS LSRs.
                  This may be relatively simple, and indeed may also be compatible with
                  the Integrated Model.
               
                  On the other hand, enhanced MPLS LSPs (i.e. LSPs signaled using some
                  GMPLS features) may be carried across an MPLS island. Success in this
                  case will depend on the particular GMPLS features in use (some
                  features, such as bi-directionality, cannot be achieved by a native
                  MPLS network without additional assistance) and the code points that
                  are used to signal the features (some objects can be carried
                  transparently across an MPLS network by virtue of their Class Number
                  encoding, but others will be silently dropped or will cause the
                  message to be rejected).
               
               6.1.1.2 Mapping
               
                  An alternative to interworking signaling protocols is to map each
                  other between MPLS and GMPLS. That is, to convert the objects carried
                  in one message to different objects carried in the message that is
                  actually sent. This mapping would be performed in an upgraded LSR at
                  island borders since existing LSRs would not be aware of the required
                  mappings. This mapping is local decision and should be pre-configured
                  or dynamically done at border nodes.
               
                  It would be relatively simple to map signaling messages for LSPs
                  initiated on MPLS LSRs (MPLS-GMPLS-MPLS and MPLS-GMPLS) since the
                  LSPs will not need to implement advanced GMPLS features. On the other
                  hand, however, mapping signaling messages for LSPs initiated by a
                  GMPLS LSR (GMPLS-MPLS-GMPLS and GMPLS-MPLS) may be considerably
                  harder depending on the GMPLS features demanded by the LSP. For
                  example, if the GMPLS LSP is bidirectional, additional function will
                  be needed at the border LSR that maps the signaling messages in order
                  to create a pair of unidirectional MPLS LSPs to carry the
                  bidirectional service across the MPLS network that does not have
                  native support for bidirectionality. Indeed, in the GMPLS-MPLS case,
                  a bidirectional service would not be possible unless the egress MPLS
                  LSR was also upgraded to provide this function.
               
                                         Expires June 2006               [Page 12]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
               
               6.1.1.3 Transfer
               
                  A migration strategy may also imply moving an MPLS state to a GMPLS
                  state. For instance, a LSR hosting MPLS states is upgraded such that
                  its controller can run both MPLS and GMPLS. In this case, a signaling
                  mechanism is needed to migrate from the MPLS LSP state to the GMPLS
                  state.
               
               6.1.2. Bidirectional LSP
               
                  GMPLS provides bidirectional LSP setup - a single signaling message
                  exchange manages the bidirectional LSP, and forward and reverse data
                  paths follow the same route in the GMPLS network. There is no
                  equivalent in MPLS networks: forward and backward LSPs must be
                  created in different signaling sessions - the route taken by those
                  LSPs may be different from each other, and their sessions are treated
                  separately. Common routes and fate sharing require additional,
                  higher-level coordination in MPLS.
               
                  If MPLS and GMPLS networks are inter-connected, bidirectional LSPs
                  from the GMPLS network need to be carried in the MPLS network.
               
                  Note that this issue arises only in the cases where an LSP is
                  originated by GMPLS-capable LSRs. In other words, it applies only to
                  the GMPLS-MPLS-GMPLS and GMPLS-MPLS island model.
               
                  Note that the island border LSRs will bear the responsibility for
                  achieving the bidirectional service across the central MPLS island.
               
                  In the MPLS-GMPLS-MPLS and MPLS-GMPLS models, the ingress LSR is
                  unaware of the concept of a bidirectional LSP and cannot attempt the
                  service even if it could find some way to request it through the
                  network. In the case of GMPLS-MPLS, a similar issue exists because
                  the egress MPLS-capable LSR is unaware of the concept of
                  bidirectional LSPs.
               
               6.1.3.Failure recovery
               
                  Failure recovery mechanism is provided using different mechanisms in
                  MPLS (see [RFC4090]) and GMPLS (see [E2E-RECOVERY, SEGMENT-RECOVERY]).
                  Local protection of island border nodes may be a particular problem.
               
               6.2. Routing
               
                  Some attention should also be given to the use of routing protocols
                  in interworking scenarios since this may allow routing information
                  from islands to be visible within the surrounding seas.
               
                                         Expires June 2006               [Page 13]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
               
                  GMPLS extends the TE information advertised by the IGPs to include
                  non-PSC information and extended PSC information. Because the GMPLS
                  information is provided as additional TLVs that are carried along
                  with the MPLS information, MPLS LSRs are able to "see" GMPLS LSRs as
                  though they were PSC LSRs. They will also see other GMPLS information,
                  but will ignore it, passing it transparently across the MPLS network
                  for use by other GMPLS LSRs.
               
                  This means that MPLS LSRs may use the MPLS information advertised by
                  MPLS LSRs and GMPLS LSRs to compute a traffic-engineered explicit
                  route across a mixed network. However, it is likely that a path
                  computation component in an MPLS network will only be aware of MPLS
                  TE information and will not understand concepts such as switching
                  capability type. This may result in that an incorrect path will be
                  computed for an e2e LSP from one MPLS island to another across a
                  GMPLS island if different switching capabilities exist.
               
               6.2.1.Interworking of Routing Protocols
               
                  GMPLS TE advertisements are based on MPLS TE advertisements with the
                  addition of extra sub-TLVs. The processing rules for unknown TLVs
                  mean that they can be ignored by a router, but must be forwarded when
                  the Link State Advertisement (OSPF LSA or IS-IS LSP) is flooded.
               
                  This means that MPLS and GMPLS LSRs may operate as routing peers, and
                  will redistribute each other's TE information. MPLS LSRs will be
                  granted full TE visibility at an MPLS level into GMPLS islands, while
                  GMPLS LSRs will have limited (i.e. MPLS-level) TE visibility into
                  MPLS islands.
               
                  This type of routing exchange may be very useful in particular for
                  MPLS-GMPLS-MPLS PSC networks. GMPLS LSRs, however, must either modify
                  their computation algorithms or must generate appropriate defaults
                  for GMPLS TE parameters that are not advertised by MPLS LSRs.
               
               6.2.2. Mapping of Routing Protocols
               
                  The alternatives to interworking routing protocols are to impose
                  protocol boundaries (such as routing area, AS boundaries) or to
                  attempt to map the protocol advertisements as they cross island
                  borders. This latter option is simple for advertisements coming from
                  GMPLS islands since the GMPLS sub-TLVs may be discarded, but is
                  pointless because those sub-TLVs are benign within the MPLS network
                  and are impossible to accurately recreate on re-entry into a GMPLS
                  network. On the other hand, advertisements initiated by MPLS LSRs
                  could have default GMPLS sub-TLVs added when they are flooded into a
                  GMPLS network. These defaults would be similar to those described in
               
                                         Expires June 2006               [Page 14]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  the previous section, and would have the advantage that GMPLS LSRs
                  within the network (i.e. not border nodes) would not need to apply
                  the defaults. Care is needed to ensure that the mechanism for
                  applying defaults is identical on all border nodes.
               
                  Note that any alternative using routing protocol mapping relies on
                  each border LSR knowing which neighbors are MPLS or GMPLS capable.
               
               6.3. Layered Networks
               
                  In addition to the difference between MPLS and GMPLS protocols,
                  control and data plane separation needs to be considered at the
                  boundary of PSC and non-PSC domains.
               
                  Note that the boundary of PSC and non-PSC domains may or may not be
                  coincident with the boundary of MPLS and GMPLS domains. In the case
                  where the boundaries are not coincident, the boundary between the PSC
                  and non-PSC domains must exist in the GMPLS domain because the MPLS
                  domain cannot support a non-PSC data plane. Here we distinguish two
                  cases: interworking between PSC and non-PSC networks, and
                  interworking between MPLS and GMPLS networks.
               
                  Figure 3 shows the network model, where the ingress PSC domain and
                  the egress PSC domains are interconnected via the transit non-PSC
                  domain.
               
                  ................. .............................. ..................
                  : Ingress PSC   : :       Transit non-PSC      : :  Egress PSC    :
                  :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
                  :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
                  :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
                  :      ________/ : :  ________/  |   ________/ : :  ________/     :
                  :     /          : : /           |  /          : : /              :
                  :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
                  :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
                  :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
                  :................: :...........................: :................:
               
                  Figure 3: Interworking of PSC and non-PSC domains.
               
                  In the PSC domain, the control plane traffic (signaling and routing)
                  is carried in-band with data. This means that there is fate sharing
                  between a data link and the control traffic on the link. On the other
                  hand, in the non-PSC domain (TDM, LSC, and FSC domains), where packet
                  delineation is not recognized, and in-band control channels cannot be
                  terminated, dedicated control channels (separated from the data
                  channels) are used. In the non-PSC domain, the control channel can be
                  logically or physically separated (i.e., in-fiber out-of-band or out-
               
                                         Expires June 2006               [Page 15]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  of-fiber out-of-bound) from the data channel depending on the
                  capabilities of the network devices and the operational requirements.
               
                  A dedicated control channel must not be used to carry user data
                  traffic. This is particularly important when the control channels are
                  of low capacity and are not designed to carry user traffic.
               
                  A possible method to protect the control plane channel of a non-PSC
                  domain is that packets coming from PSC domains are not allowed to use
                  the control plane channel. The method, however, causes another
                  problem: lack of signaling and routing adjacencies across the non-PSC
                  domain.
               
                  This problem is explained using Fig. 3. LSAs in the egress PSC domain
                  are not advertised in the ingress PSC domain unless routing
                  adjacencies are established between the PSC domain and non-PSC domain
                  or unless routing adjacencies are established directly between PSC
                  domains. Therefore the ingress LSR in the ingress PSC domain is not
                  able to find the egress LSR in the egress PSC domain unless these
                  adjacencies are formed. The signaling messages are not passed across
                  the non-PSC domain between the ingress and the egress PSC domains
                  unless the signaling adjacencies are established between the PSC
                  domain and the non-PSC domain or directly between PSC domains.
               
                  Interworking between PSC and non-PSC networks can be regarded as a
                  layered network. Layered networks are described in many places
                  including [RFC3945] and [RFC4206]. [MRN-REQ] gives a good background
                  and discusses some of the requirements for multi-layered networks.
               
                  Network layering is often used to separate domains of different data
                  plane technology. It can also be used to separate domains of
                  different control plane technology (such as MPLS and GMPLS protocols),
                  and the solutions developed for multiple data plane technologies can
                  be usefully applied to this situation.
               
                  The GMPLS architecture [RFC3945] identifies three architectural
                  models for supporting multi-layer GMPLS networks, and these models
                  may be applied to the separation of MPLS and GMPLS control plane
                  islands. The applicability of the different migration models to the
                  three architectural models may provide additional input to the choice
                  of an architectural model.
               
               6.3.1. Peer Model
               
                  In the peer model, both MPLS and GMPLS nodes run the same routing
                  instance and routing advertisements, from within islands of one level
                  of protocol support are distributed to the whole network. This is
               
               
                                         Expires June 2006               [Page 16]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  achievable as described in section 6.2 either by direct distribution
                  or by mapping of parameters.
               
                  If the entire network (MPLS and GMPLS capable LSRs) is PSC, signaling
                  may establish end-to-end LSPs using the techniques described in
                  section 6.1. On the other hand, if the GMPLS network is of some other
                  switching type, or if the protocol islands are managed as separate
                  network layers, the signaling request can give rise to the creation
                  of a hierarchical LSP [RFC4206] or stitching segment [STITCH] that
                  spans an island and is triggered when the LSP request reaches the
                  island border. The end-to-end LSP from the higher layer network (the
                  protocol sea) is carried across the lower layer network (the protocol
                  island) by the tunnel or stitching segment.
               
                  Note that an MPLS sea is not capable of determining whether the
                  entire network is of the same switching type and will consequently
                  attempt to signal end-to-end LSPs assuming them to be PSC all the way.
                  This requires that the island border take the appropriate action to
                  set up tunnels across islands of different switching capabilities.
               
               6.3.2. Overlay Model
               
                  The overlay model preserves strict separation of routing information
                  between network layers. Thus, in the interworking case, there is no
                  requirement to handle routing interworking. Signaling interworking is
                  still required as described in section 6.1.
               
                  Note, however, that there is a requirement to create signaling higher
                  layer adjacencies between island border nodes, and that it is highly
                  desirable to create routing adjacencies in the same way. Such
                  adjacencies may use the control plane of the lower layer network and
                  be independent of the existence of data plane connectivity across the
                  lower layer network. Care may be required to prevent the swamping of
                  the lower layer control plane when it has limited capacity.
                  Alternatively, such adjacencies may rely on the existence of data
                  plane connectivity across the lower layer network.
               
               6.3.3. Augmented Model
               
                  The augmented model allows limited routing exchange from the lower
                  layer network to the higher layer network. Generally speaking, this
                  assumes that the border nodes provide some form of filtering, mapping
                  or aggregation of routing information advertised from the lower layer
                  network, and this is compatible with the mechanisms described in
                  section 6.2.2.
               
                  Note however, that part of this assumption allows the border nodes to
                  have full visibility into both the higher and lower layer networks
               
                                         Expires June 2006               [Page 17]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  without further advertising the information from the lower layer
                  network to the higher layer network meaning that no mapping or
                  interworking of routing protocols is required. Particularly, this
                  includes the case where MPLS and GMPLS clouds run distinct routing
                  instances, and the border nodes run both routing instances.
               
                  Note that the same observations about routing and signaling
                  adjacencies apply as for the overlay model.
               
               
               7.Manageability Considerations
               
                  Some attention should be given during migration planning to how the
                  network will be managed during and after migration. For example, will
                  the LSRs of different protocol capabilities be managed separately or
                  as a whole. This is most clear in the Island Model where it is
                  possible to consider managing islands of one capability separately
                  from the surrounding sea. In the case of islands that have different
                  switching capabilities, it is possible that the islands already had
                  different management in place before the migration: the resultant
                  migrated network may seek to merge the management or to preserve it.
               
               7.1. Control of Function and Policy
               
                  The most important control to be applied is at the moment of
                  changeover between different levels of protocol support. Such a
                  change may be made dynamically or during a period of network
                  maintenance.
               
                  Where island boundaries exist, it must be possible to manage the
                  relationships between protocols and to indicate which interfaces
                  support which protocols on a border LSR. Further, island borders are
                  a natural place to apply policy, and management should allow
                  configuration of such policies.
               
               7.2. Information and Data Models
               
                  No special information or data models are required to support
                  migration, but note that migration in the control plane implies
                  migration from MPLS management tools to GMPLS management tools.
                  During migration, therefore, it may be necessary for LSRs and
                  management applications to support both MPLS and GMPLS variants of
                  management data.
               
                  The GMPLS MIB modules are designed to allow support of the MPLS
                  protocols and build on the MPLS MIB modules through extensions and
                  augmentations. This may make it possible to migrate management
                  applications ahead of the LSRs that they manage.
               
                                         Expires June 2006               [Page 18]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
               
               7.3. Liveness Detection and Monitoring
               
                  Migration will not imposes additional issues for OAM above those that
                  already exist for inter-domain OAM and for OAM across multiple
                  switching capabilities.
               
                  Note, however, that if a flat PSC MPLS network is migrated using the
                  island model, and is treated as a layered network using tunnels to
                  connect across GMPLS islands, then requirements for a multi-layer OAM
                  technique may be introduced into what was previously defined in the
                  flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking
                  may be described in more detail in a later version.
               
               7.4. Verifying Correct Operation
               
                  The concerns for verifying correct operation (and in particular
                  correct connectivity) are the same as for liveness detection and
                  monitoring. Principally, the process of migration may introduce
                  tunneling or stitching into what was previously a flat network.
               
               7.5.Requirements on Other Protocols and Functional Components
               
                  No particular requirements are introduced on other protocols. As it
                  has been observed, the management components may need to migrate in
                  step with the control plane components, but this does not impact the
                  management protocols, just the data that they carry.
               
                  It should also be observed that providing signaling and routing
                  connectivity across a migration island in support of a layered
                  architecture may require the use of protocol tunnels (such as GRE)
                  between island border nodes. Such tunnels may impose additional
                  configuration requirements at the border nodes.
               
               7.6. Impact on Network Operation
               
                  The process of migration is likely to have significant impact on
                  network operation while migration is in progress. The main objective
                  of migration planning should be to reduce the impact on network
                  operation and on the services perceived by the network users.
               
                  To this end, planners should consider reducing the number of
                  migration steps that they perform, and minimizing the number of
                  migration islands that are created.
               
                  A network manager may prefer the island model especially when
                  migration will extend over a significant operational period because
                  it allows the different network islands to be administered as
               
                                         Expires June 2006               [Page 19]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  separate management domains. This is particularly the case in the
                  overlay and augmented network models where the details of the
                  protocol islands remain hidden from the surrounding LSRs.
               
               7.7. Other Considerations
               
                  No other management considerations arise.
               
               
               8. Security Considerations
               
                  Security and confidentiality is often applied (and attacked) at
                  administrative boundaries. Some of the models described in this
                  document introduce such boundaries, for example between MPLS and
                  GMPLS islands. These boundaries offer the possibility of applying or
                  modifying the security as one might when crossing an IGP area or AS
                  boundary, even though these island boundaries might lie within an IGP
                  area or AS.
               
                  No changes are proposed to the security procedures built into MPLS
                  and GMPLS signaling and routing. GMPLS signaling and routing inherit
                  their security mechanisms from MPLS signaling and routing without any
                  changes. Hence, there will be no issues with security in interworking
                  scenarios. Further, since the MPLS and GMPLS signaling and routing
                  security is provided on a hop-by-hop basis, and since all signaling
                  and routing exchanges described in this document for use between any
                  pair of LSRs are based on either MPLS or GMPLS, there are no changes
                  necessary to the security procedures.
               
               
               9. IANA Considerations
               
                  This information framework document makes no requests for IANA action.
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
                                         Expires June 2006               [Page 20]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
               10. 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.
               
               
               11. Intellectual Property
               
                  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.
               
               
               12. Acknowledgements
               
                  The authors are grateful to Daisaku Shimazaki for discussion during
                  initial work on this document.
               
               
               
                                         Expires June 2006               [Page 21]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
               13. Authors' Addresses
               
                  Kohei Shiomoto
                  NTT
                  Midori 3-9-11
                  Musashino, Tokyo 180-8585, Japan
                  Phone: +81 422 59 4402
                  Email: shiomoto.kohei@lab.ntt.co.jp
               
                  Eiji Oki
                  NTT
                  Midori 3-9-11
                  Musashino, Tokyo 180-8585, Japan
                  Phone: +81 422 59 3441
                  Email: oki.eiji@lab.ntt.co.jp
               
                  Ichiro Inoue
                  NTT
                  Midori 3-9-11
                  Musashino, Tokyo 180-8585, Japan
                  Phone: +81 422 59 3441
                  Email: inoue.ichiro.lab.ntt.co.jp
               
                  Dimitri Papadimitriou
                  Alcatel
                  Francis Wellensplein 1,
                  B-2018 Antwerpen, Belgium
                  Phone: +32 3 240 8491
                  Email: dimitri.papadimitriou@alcatel.be
               
                  Jean-Louis Le Roux
                  France Telecom R&D
                  av Pierre Marzin 22300
                  Lannion, France
                  Phone: +33 2 96 05 30 20
                  Email: jeanlouis.leroux@francetelecom.com
               
                  Deborah Brungard
                  AT&T
                  Rm. D1-3C22 - 200 S. Laurel Ave.
                  Middletown, NJ 07748, USA
                  Phone: +1 732 420 1573
                  Email: dbrungard@att.com
               
                  Kenji Kumaki
                  KDDI Corporation
                  Garden Air Tower
                  Iidabashi, Chiyoda-ku,
               
                                         Expires June 2006               [Page 22]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  Tokyo 102-8460, JAPAN
                  Phone: +81-3-6678-3103
                  Email: ke-kumaki@kddi.com
               
               
               14. References
               
               14.1. Normative References
               
                  [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                                 Requirement Levels," BCP 14, IETF RFC 2119, March 1997.
               
                  [RFC4090]     Pan, P., Swallow, G. and A. Atlas, "Fast Reroute
                                 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
                                 2005.
               
                  [RFC3945]     Mannie, E., "Generalized Multi-Protocol Label
                                 Switching Architecture", RFC 3945, October 2004.
               
                  [SEGMENT-RECOVERY]   Berger, L., "GMPLS Based Segment Recovery",
                                 draft-ietf-ccamp-gmpls-segment-recovery, work in
                                 progress.
               
                  [E2E-RECOVERY]
                                 Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors),
                                 " RSVP-TE Extensions in support of End-to-End
                                 Generalized Multi-Protocol Label Switching (GMPLS)-
                                 based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-
                                 signaling, work in progress.
               
                  [RFC3473]     Berger, L., "Generalized Multi-Protocol Label
                                 Switching (GMPLS) Signaling Resource ReserVation
                                 Protocol-Traffic Engineering (RSVP-TE) Extensions ",
                                 RFC 3473, January 2003.
               
               
               14.2. Informative References
               
                  [MRN-REQ]     Shiomoto, K., Papadimitriou, D., Le Roux, J.L.,
                                 Vigoureux, M., Brungard, D., "Requirements for GMPLS-
                                 based multi-region and multi-layer networks", draft-
                                 shiomoto-ccamp-gmpls-mrn-reqs, work in progress.
               
               
                  [RFC4206]     Kompella, K., and Rekhter, Y., "Label Switched Paths
                                (LSP) Hierarchy with Generalized Multi-Protocol Label
                                Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
                                October 2005.
               
               
                                         Expires June 2006               [Page 23]
               

               draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt         March 2006
               
               
                  [STITCH]      Ayyangar, A., Vasseur, JP. "Label Switched Path
                                Stitching with Generalized MPLS Traffic Engineering",
                                draft-ietf-ccamp-lsp-stitching, work in progress.
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
                                         Expires June 2006               [Page 24]
               

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/