Internet DRAFT - draft-oki-ccamp-gmpls-ip-interworking
draft-oki-ccamp-gmpls-ip-interworking
Network Working Group D. Brungard (ATT)
Internet Draft J.L. Le Roux (FT)
Proposed Category: Standards Track E. Oki (NTT)
Expires: January 2006 D. Papadimitriou (Alcatel)
D. Shimazaki (NTT)
K. Shiomoto (NTT)
July 2005
IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS
migration
draft-oki-ccamp-gmpls-ip-interworking-06.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 (2005). All Rights Reserved.
Abstract
Over time Multi-Protocol Label Switching (MPLS) traffic
engineered networks may be migrated to use Generalized MPLS
(GMPLS). This will allow the networks to benefit from many new
features that have been added to the GMPLS protocols.
Additionally, such migration will facilitate easy interworking
of packet networks that are controlled by IP/MPLS-TE protocols
and networks that are controlled by GMPLS protocols.
During this migration phase MPLS and GMPLS capable elements will
have to co-exist and interwork. GMPLS signaling and routing
protocols are subtly different from the MPLS protocols and so
interworking and migration strategies are needed.
This document describes issues associated with interworking of
IP/MPLS-TE networks and GMPLS-based optical networks. Then it
describes possible migration scenarios, mechanisms to compensate
for the differences between MPLS and GMPLS protocols, and how to
apply those mechanisms in order to achieve migration from MPLS
to GMPLS.
Expires Janurary 2006 [Page 1]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
Table of Contents
1. Introduction...................................................2
2. Interworking between MPLS-based packet network and GMPLS-
based optical transport network...................................2
2.1. Issues.......................................................2
2.1.1. Lack of routing and signaling adjacencies..................2
2.1.2. Control plane resource exhaustion..........................2
2.1.3. TE path computation over the border between MPLS and
GMPLS domains.....................................................2
3. Migration scenarios............................................2
3.1. Migration Models.............................................2
3.2. MPLS-GMPLS(non-PSC)-MPLS Islands.............................2
3.3. MPLS-GMPLS(PSC)-MPLS Islands.................................2
3.4. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands...........................2
3.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands..................2
3.6. Integrated Migration Model for PSC...........................2
4. Difference between MPLS and GMPLS protocols....................2
4.1. Routing......................................................2
4.2. Signaling....................................................2
4.3. Control plane/data plane separation..........................2
4.4. Bidirectional LSPs...........................................2
5. Required mechanisms for the MPLS-GMPLS-MPLS migration model....2
5.1. Routing......................................................2
5.1.1. TE link....................................................2
5.1.2. Discovery of GMPLS signaling capability....................2
5.2. Path computation.............................................2
5.3. Signaling....................................................2
5.3.1. LSP nesting................................................2
5.3.2. LSP stitching..............................................2
5.3.3. Contiguous LSPs............................................2
6. Required mechanisms for other migration models.................2
7. Security considerations........................................2
8. IANA Considerations............................................2
9. Acknowledgments................................................2
10. References....................................................2
10.1. Normative references........................................2
10.2. Informative references......................................2
11. Authors' Addresses............................................2
12. Intellectual Property Statement...............................2
13. Disclaimer of Validity........................................2
14. Copyright Statement...........................................2
1. Introduction
Multi-protocol label switching (MPLS) is widely deployed with
applications such as Traffic Engineering (TE) and Virtual
Private Networks (VPN). Various kinds of services such as VoIP,
IPv6, L2VPN/L3VPN, and pseudo wire emulation are expected to
converge over the MPLS-based controlled packet switching
infrastructure network.
Many service providers report that traffic volume is increasing
tremendously as broadband services enabled by ADSL and FTTH are
rapidly penetrating the market, and the processing performance
of terminal and server is ever increasing. In order to cope with
such an increase in the traffic volume, optical networks, which
consist of TDM, LSC, and FSC devices, are being introduced.
Generalized MPLS (GMPLS) is being standardized by extending MPLS
to control such optical networks (see [2], [3], [9], [10], [11],
[12]) in addition to Layer-2 Switching Capable (L2SC) and Packet
Expires January 2006 [Page 2]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
Switching Capable (PSC) networks [6]). GMPLS networks will be
deployed as part of the existing MPLS infrastructure to extend
the reach and capacity of MPLS networks.
Additionally, GMPLS PSC devices and networks will be deployed to
take advantage of new features and functions that have been
added to the GMPLS protocols but which are not present in MPLS.
These include features such as bi-directional LSPs, label
suggestion, label restriction, graceful restart, and graceful
teardown as well as explicit support for network to host
multiple switching capabilities. (see [6]). GMPLS also provides
several features in a distinct manner from MPLS. For instance
local protection is provided using distinct mechanisms in MPLS
(see [17]) and GMPLS (see [18]). Migration from MPLS to GMPLS
will bring these features and such distinct mechanisms into the
existing MPLS-based controlled infrastructure network.
MPLS and GMPLS devices will coexist in the network until the
existing MPLS network is completely migrated to the GMPLS
network. This means that MPLS and GMPLS devices must interwork
to deliver services for the user.
GMPLS protocols are, however, subtly different from the MPLS
protocols. In order to migrate from the existing MPLS to the
GMPLS network, we need to define mechanisms to compensate the
difference between MPLS and GMPLS. In this document we discuss
the migration scenarios from MPLS to GMPLS networks, mechanisms
to compensate for the differences between MPLS and GMPLS, and
the applicability of the mechanisms to the possible migration
scenarios. Some of the mechanisms described in this document use
existing techniques; others introduce new techniques.
Note that GMPLS covers Packet Switching Capable (PSC) networks
[6]. In the rest of this document, the term GMPLS includes both
PSC and non-PSC. Otherwise the term "PSC GMPLS" or "non-PSC
GMPLS" is explicitly used.
2. Interworking of IP/MPLS-TE networks and GMPLS-based networks
2.1. Issues
In order to expand the network capacity, GMPLS-based optical
networks are likely to be deployed underneath the already-
deployed MPLS-based networks. We need "interworking" mechanisms
between MPLS and GMPLS-based optical networks because the LSRs
in the already-deployed MPLS-based networks may not be GMPLS-
capable. Even if the control plane of the already-deployed MPLS-
based networks will be "migrated" from MPLS to GMPLS, such
interworking mechanisms are also required during the migration
process because GMPLS-incapable LSRs and GMPLS-capable LSRs
coexist until all the LSRs become GMPLS-capable. This section is
devoted to highlight the issues on interworking between MPLS-
based packet networks and GMPLS-based networks.
There are several architectural alternatives for interworking
between packet network and optical transport network: overlay,
integrated and augmented models [RFC3945]. We also address the
issues from the point of view of these different architectural
alternatives.
Three issues on interworking between MPLS-based packet networks
and GMPLS-based optical transport network result from the fact
that control and data planes are separated in GMPLS-based
optical transport networks. These three issues are (1) lack of
Expires January 2006 [Page 3]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
routing and signaling adjacencies, (2) control plane resource
exhaustion, and (3) TE path computation over the border between
MPLS and GMPLS domains. These issues are explained using an
example network shown in Fig. 1.
................. .............................. ..................
: Ingress MPLS : : GMPLS-based optical : : Egress MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
: / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
Figure 1: Interworking of MPLS-TE networks and GMPLS-based
optical transport networks.
2.1.1. Lack of routing and signaling adjacencies
The ingress MPLS and the egress MPLS domains are interconnected
via a GMPLS-based optical network as shown in Fig X1. LSAs in
the egress MPLS domain are not advertised in the ingress MPLS
domain unless routing adjacencies are established between the
IP/MPLS domain and GMPLS domain. Therefore the ingress LSR in
the ingress MPLS domain is not able to find the egress LSR in
the egress MPLS domain. The signaling messages are not passed
across the GMPLS domain between the ingress and the egress MPLS
domains unless the signaling adjacencies are established between
the MPLS domain and the GMPLS domain.
This issue appears in the augmented and the overlay model.
2.1.2. Control plane resource exhaustion
In GMPLS-based optical domain, the control plane is not designed
for carrying user data traffic packets separates control and
data planes. If the user data traffic between ingress and egress
MPLS domains is routed onto the control plane of the GMPLS-based
optical domain, it would exhaust the control plane resource. Use
data traffic between ingress and egress domains MUST NOT be
carried using the control plane of GMPLS-based optical domain.
This issue can appear in the integrated, the augmented, and the
overlay models depending on how the border node handles the data
forwarding and manages the address space.
2.1.3. TE path computation over the border between MPLS and GMPLS
domains
If the ingress LSR in the ingress MPLS domain does not
understand the GMPLS TE protocols and information elements, it
assumes that there is no available TE-path across the GMPLS
domain unless MPLS-compatible TE LSAs representing the available
TE-paths in the GMPLS domain are advertised into the ingress and
egress MPLS domains.
This issue appears in the integrated and the augmented models.
A different issue, which has very similar results, appears in
the overlay model. In the overlay model, we need to find
connectivity between IP/MPLS domains across the core GMPLS
Expires January 2006 [Page 4]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
domain. This issue is referred to as the ææunknown adjacencyÆÆ
problem.
2.2 Solutions
The required mechanisms to address the above-mentioned issues
are described in section 5. Applicability of these mechanisms
will be addressed in a separate document.
3. Migration scenarios
3.1. Migration Models
Two migration models are considered.
In the first model, an MPLS network has islands of GMPLS
capability introduced. These islands may be networks of devices
operating at a lower network layer (for example, TDM), or may be
clusters of PSC devices that are controlled by GMPLS protocols.
The smallest island can contain just one device. Over time,
collections of MPLS devices are replaced or upgraded to create
new GMPLS islands or to extend existing ones.
From a migration interworking point of view, we need to examine
how these islands are positioned and how LSPs run between the
islands. Three categories of migration scenarios are considered:
(1) MPLS-GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, and (3) MPLS-GMPLS.
In each case, the interworking behavior is examined based on
whether the GMPLS islands are PSC or non-PSC.
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. Further,
existing MPLS devices are 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-capable
devices it may be routed accordingly and achieve a higher level
of functionality by utilizing GMPLS features. Once all devices
in the network are GMPLS-capable, the MPLS protocols may be
turned off, and no new devices need to support MPLS.
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.
Practically speaking, both migration models may be deployed at
the same time giving rise to a network of mixed MPLS and GMPLS
devices with islands of just MPLS or just GMPLS capability.
3.2. MPLS-GMPLS(non-PSC)-MPLS Islands
The introduction of a GMPLS-based controlled optical core
network to increase the capacity is an example of this scenario.
TDM, LSC, and/or FSC LSPs are established between MPLS networks
across the GMPLS network. A set of those LSPs provide virtual
network topology to connect the MPLS networks. This topology may
be reconfigurable by adding and/or removing those LSPs [15][16].
MPLS domains interconnected at the edges of the virtual network
topology may form a single MPLS network. Figure 2 shows the
reference network model for the MPLS-GMPLS(non-PSC)-MPLS
migration. The model consists of three islands: ingress, transit,
and egress. Both the ingress and egress islands are MPLS-based
while the transit island is GMPLS-based. The nodes at the
Expires January 2006 [Page 5]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
boundary of the MPLS and GMPLS islands (G1, G2, G5, and G6) are
referred to as "island border nodes". All nodes except the
island border nodes in the GMPLS-based transit island (G3 and
G4) are non-PSC devices, i.e., optical equipment (TDM, LSC, and
FSC). An MPLS LSP can be provisioned from a node in the ingress
MPLS-based island (say, R2) to a node in the egress MPLS-based
island (say, R4). The LSP is referred to as the end-to-end (e2e)
LSP. The switching capability type of both end points of the e2e
LSP are the same (PSC).
................. .............................. ..................
: MPLS : : GMPLS (non-PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
: / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<-------------------------------------------------------->|
e2e LSP
Figure 2: MPLS-GMPLS(non-PSC)-MPLS island migration model.
3.3. MPLS-GMPLS(PSC)-MPLS Islands
An MPLS-based network can be migrated to become a GMPLS (PSC)-
based network.
The rationale of this type of migration scenario is supported by
two factors:
1. to provide GMPLS-based advanced features in the network
2. to facilitate interworking with GMPLS-based
optical core network.
Numerous advanced features are being developed in GMPLS and MPLS,
but many are only currently available in a GMPLS context. An
existing MPLS-based network could be migrated to become a GMPLS
(PSC)-based network to deliver the advanced features. Once the
PSC network has been migrated to use GMPLS, it could be migrated
to be or work with a GMPLS-based optical core network with less
effort. Thus, for example, the network might be constructed from
five islands so that an e2e LSP traversed MPLS-(PSC)GMPLS-(non-
PSC)GMPLS-(PSC)GMPLS-MPLS. The migration interworking strategy
would be implemented between MPLS and (PSC)GMPLS islands without
the complexity of handling the change in switching capability
described in the previous model.
3.4. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands
In this scenario, GMPLS PSC e2e LSPs are provisioned in the
GMPLS network, which is disconnected. The MPLS-based controlled
infrastructure is used to bridge the disconnected GMPLS networks.
This scenario 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.
Since the MPLS-based controlled network is PSC, the GMPLS PSC
LSP can cross MPLS-based converged network without extra
Expires January 2006 [Page 6]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
treatment in data plane. Note, however, that the level of
service available in the GMPLS islands is more extensive than
that available in the MPLS island because of the differences in
the signaling protocols. The migration challenge in this model
is to provide the expected level of service across the MPLS
island, and to carry the GMPLS signaling and routing information
across the MPLS island.
3.5. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands
This scenario is for further study.
3.6. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands
In this scenario an LSP starts/ends in the GMPLS (PSC) island
and ends/starts in the MPLS island. Some signaling and routing
conversion is required on island border LSRs. This migration
model is likely to arise where the migration strategy is not
based on a core infrastructure, but has edge nodes (ingress or
egress) located in the islands of different capabilities.
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.
Figure 4 shows the reference model for this migration scenario.
Head-End and Tail-end LSR are in distinct control plane regions.
................. .................................
: MPLS : : GMPLS (PSC) :
:+---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |:
:+---+ +---+ +---+ +-+-+ +---+:
: ________/ : : ________/ | ________/ :
: / : : / | / :
:+---+ +---+ +---+ +-+-+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |:
:+---+ +---+ +---+ +---+ +---+:
:................: :...............................:
|<------------------------------------------->|
e2e LSP
Figure 4: GMPLS-MPLS migration model.
3.7. Integrated Migration Model for PSC
The integrated migration model results in a single network in
which both MPLS-capable and GMPLS-capable LSRs co-exist. Some
LSRs will be capable of only one protocol, and some of both. The
migration strategy here is involves introducing GMPLS-capable
LSRs into an existing MPLS-capable network until such time as
all LSRs are GMPLS-capable at which time all MPLS functionality
is disabled.
Since all devices are PSC 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.
Note that this is a contrast with the models described above.
4. Difference between MPLS and GMPLS protocols
Expires January 2006 [Page 7]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
4.1. Routing
TE-link information is advertised by the IGP using TE extensions.
This allows LSRs to collect topology information for the whole
TE network and to store it in the traffic-engineering data base
(TED). Traffic-engineered explicit routes are calculated using
the network graphs derived from the TED.
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 extensions to 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 combination of MPLS
information advertised by MPLS LSRs and a restricted subset of
the information advertised by 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 mean 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.
Figure 5 illustrates this problem. Suppose that an e2e LSP is
required between R2 and R4 and that we need to compute the path
between R2 and R4. The TE link information for the links R2-R21,
R21-G2, G6-R41 and R41-R4 is MPLS-based, while the information
for the links G2-G4, G2-G3, G3-G4 and G4-G6 is GMPLS-based. The
node in the MPLS-based ingress region (say, R2) may compute a
path using the TE link information that it is aware of, and may
produce a path R2-R21-G2-G4-G6-R41-R4. But it may be the case
that the links G2-G4 and G4-G6 cannot be connected because they
have different switching capabilities. A path from G2 to G4
through G3 would, however, be successful. If R2 was able to
process the GMPLS TE information advertised by the IGP it would
see the switching capability information and would select the
correct path, but since it is an MPLS node it selects the wrong
path based on the limited MPLS TE information.
................. ............................. ..................
: MPLS : : GMPLS (non-PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
: / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<---->|<----->|<------------>|<------------>|<----->|<---->|
MPLS TE-link GMPLS TE-link GMPLS TE-link MPLS TE-link
Figure 5: Problem mismatch of TE-link information in MPLS and
GMPLS.
4.2. Signaling
Expires January 2006 [Page 8]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
GMPLS RSVP-TE signaling ([2]) introduces new RSVP-TE objects,
and their associated procedures, that are no processed/generated
by MPLS LSRs:
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 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 bi-directional LSP setup
(see also Section 3.4)
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 Notify Request object used to solicit notification of
errors and events.
o The Protection object used to indicate the required
protection scheme (and the Association object used to
associated protected and protecting LSPs).
O Alarm_Spec object to exchange (per LSP) alarm information
across the control plane
Some of these objects can be passed transparently by MPLS LSRs
because their C-Nums are of the form 11bbbbbb, or simply
discarded and ignored because their C-Nums are of the form
10bbbbbb, but others will cause an MPLS LSR to reject the
message that carries them because their C-Nums are of the form
0bbbbbbb.
Even some objects that GMPLS inherits from MPLS can be expected
to cause problems. For example, the Label object in GMPLS uses
two new C-Types to indicate æGeneralized LabelÆ. These C-Types
are unknown to MPLS LSRs which 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 a new message, the Notify message, that is
not supported by MPLS nodes.
Note also that ongoing GMPLS extensions (P&R, Graceful Restartà)
add new objects and messages. Future GMPLS extensions are also
likely to add further messages and objects.
4.3. Control plane/data plane separation
In MPLS, the control plane traffic (signaling and routing) is
carried in-band with data. This means that there is fare sharing
between a data link and the control traffic on the link. The
control plane keep-alive techniques can be used to detect data
plane failures.
TDM, LSC, FSC networks do not recognize packet delineation, so
GMPLS must support control channel that can be logically (in-
band) or physically (out-of-band) separated from the data
channel depending on the capabilities of the devices interfaces
and the operational requirements.
Expires January 2006 [Page 9]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
The GMPLS control plane, which is designed to carry the control
packets in a GMPLS network, does not form part of the data
network and must not be used to carry data. This is particularly
important since the control channel may be of low capacity and
is not designed to carry user traffic.
The problem may be seen at packet-capable LSRs that may see
unlabeled IP packets, and that also have out-of-band control
channels on some interfaces. In these cases it is possible that
the IP traffic will be routed along a control channel according
to the shortest path determined by the IGP.
Appropriate precautions must be taken to protect out-of-band
control channels.
4.4. Bidirectional LSPs
GMPLS provides bidirectional LSP setup - a single signaling
session 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 differently from each other. Common routes and fate
sharing require additional, higher-level coordination in MPLS.
If MPLS and GMPLS networks are inter-connected, bidirectional
LSPs from GMPLS network need to be carried in MPLS network.
Note that this issue arises only in the cases where an LSP is
originated and terminated by GMPLS-capable LSRs. In other words,
it applies only to the GMPLS-MPLS-GMPLS, GMPLS-MPLS and
integrated migration models. 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
and cannot initiate a return LSP even if it could be told that
the need existed.
Functionally, this is a reasonable restriction because only
GMPLS-capable LSRs will need to be the ingress or egress of a
bidirectional service.
Note that the island border LSRs will bear the responsibility
for achieving the bidirectional service across the central MPLS
island.
5. Required mechanisms for the MPLS-GMPLS-MPLS migration model.
This section details the set of routing, path computation and
signaling mechanisms required in order to bridge the differences
between MPLS and GMPLS protocols with regards to the MPLS-GMPLS-
MPLS migration model.
The entire network consisting of ingress, transit, and egress
regions (See Figure 1 or Figure 2 for instance) may be managed
either as a single area or as multiple areas from the IGP
perspective.
Note that a simple migration approach can consist of separating
MPLS and GMPLS networks into distinct IGP areas (possibly in
Expires January 2006 [Page 10]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
distinct ASs), and then relying on multi-area (multi-AS) routing,
path computation, and signaling solutions worked on in the CCAMP
and PCE WGs.
5.1. Routing
5.1.1. TE link
If the entire network is a single area, the partial topology of
GMPLS-based region which consists of PSC-links should be made
visible to the MPLS islands. GMPLS PSC TE-links are also
advertised into the MPLS islands as MPLS TE-links using MPLS-
based TE link information. The GMPLS-capable LSR advertises both
GMPLS and MPLS TE LSAs for the same TE link. If the GMPLS-based
region contains non-PSC links or devices (for example, if the
whole region is non-PSC with the exception of the edge devices)
PSC links should be set up between the PSC capable devices (for
example, the border nodes). For example, in Figure 3, a PSC-link
can be set up between G2 and G6. Note that the FA LSPs that
realize these PSC links could be statically provisioned in a
full mesh across the GMPLS island or created dynamically on
demand although the Virtual Network Topology (VNT) must be
advertised to the MPLS islands.
Note also that MPLS TE-links could be advertised even in the
absence of PSC FA-LSP between two border nodes. Such TE-links
are called virtual TE-links (see [15]).
MPLS TE-links may be understood by the nodes in the GMPLS
network, as they build their TEDs.
There is no backward compatibility issue when MPLS and GMPLS
LSRs resides in distinct IGP areas, as TE-link information is
not leaked across area boundary (see [24] and [21]).
5.1.2. Discovery of GMPLS signaling capability
It may be useful to advertise the signaling capabilities
(specifically, the ability to support GMPLS) using the IGP. This
would allow every node in the network to automatically discover
the GMPLS signaling islands.
This could be achieved using the techniques proposed in [25] or
could be deduced from the presence of GMPLS TE information for
any link advertised by an LSR (provided that GMPLS routing
support implies GMPLS signaling support).
There are several options for how the islands are managed from a
routing perspective. They could all be managed as a single area,
they could be managed as separate areas, or they could be
operated as separate ASs. In the second and third cases, it a
node will sit on the border between the islands and act as an IP
border node (ABR or ASBR) but only be capable of running MPLS or
GMPLS within the appropriate island. That is, the ABR or ASBR
cannot participate in signaling within both islands. Such LSRs
will be no use as island border LSRs and must be recognized as
such and excluded from any end-to-end signaling attempts.
5.2. Path computation
When each of the islands in the MPLS-GMPLS-MPLS scenario is
located in a separate TE domain, the path computation for TE
LSPs should be performed strictly following the procedures
described in the [21]. In that case route resolution can be
Expires January 2006 [Page 11]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
performed using loose hops (see [26]) or the Path Computation
Element based approach [27].
However, if all islands are resident within a single TE domain
(e.g. an IGP area) the explicit end-to-end paths can be
determined on the ingress LSRs (which are MPLS-capable in this
scenario). Note that it is implicit in the statement that, when
the islands are within a single TE domain, the GMPLS-capable
LSRs advertise both GMPLS and MPLS TE link sub-TLVs.
In this scenario, however, an ingress MPLS-capable LSR may
compute a path that cannot function because of incompatible
GMPLS parameters (for example, switching capabilities or per-
priority bandwidth) as described in section 3.1. Therefore,
where this issue may arise, FA-LSP sould be setup between border
nodes and advertised as MPLS TE-links, and/or virtual MPLS TE-
links may be used (see section 5.1.1)
5.3. Signaling
There are three mechanisms that could be used for MPLS-GMPLS-
MPLS interworking irrespective of whether the sections are
located in the same or separate TE domains. The three mechanisms
are:
o LSP nesting
o LSP stitching
o Contiguous LSPs with MPLS<->GMPLS signaling translation.
The LSP nesting is recommended when GMPLS and MPLS links belong
to different network layers (the case of non-PSC GMPLS or PSC1
MPLS & PSC2 GMPLS for instance). The other two mechanisms could
be used when all islands provide network topology within the
same network layer (the case of PSC GMPLS).
5.3.1. LSP nesting
In the MPLS-GMPLS-MPLS scenario the GMPLS links may have
different switching capabilities compared to the MPLS links.
End-to-end LSPs in this case could be carried across the GMPLS
island by hierarchical LSPs established between the island
border nodes.
When the setup request for an end-to-end LSP reaches the GMPLS
island, an attempt is made to find a locally originated H-LSP
that terminates at the far side of the GMPLS island, and that
has the required attributes and unreserved bandwidth. The H-LSP
may be pre-provisioned via management, or may have been created
dynamically to satisfy some previous request. If such a pre-
existing H-LSP is not found, the establishment of the end-to-end
LSP is paused while a new H-LSP is established. Once an H-LSP
has been found or established, the signaling of the end-to-end
LSP proceeds using the H-LSP as a data link.
The H-LSPs may optionally be advertised as MPLS TE links into
the MPLS islands. Such H-LSP is referred to as an FA-LSP [19].
The H-LSPs advertised as TE links provide the Virtual Network
Topology for MPLS layer. TE-LSPs guarantee efficient usage of
their bandwidth because those TE-links are present in the TED
and can be considered in future path computations for the
placement of further end-to-end LSPs.
Hierarchical LSPs offer scaling advantages of aggregation across
the central GMPLS island, and facilitate localized recovery and
Expires January 2006 [Page 12]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
re-optimization in the GMPLS island without requiring end-to-end
action.
5.3.2. LSP stitching
LSP stitching is described in [28]. Stitching may be operated
exactly as described for FA-LSPs in the previous section. Note,
however that only one end-to-end LSP can be carried by a
stitching segment at any time.
LSP stitching is primarily targeted at the case where all
islands operate the same switching type. Note that the switching
capability of an LSP segment TE link MUST be equal to the
switching type of the underlying LSP segment; i.e. no hierarchy
(nesting) is possible [28].
LSP stitching does not require the protocol mapping of
contiguous LSPs (see below) but does require more protocol state
at the island border nodes. It offers more flexibility with
regard to LSP recovery and re-optimization since the LSP segment
across the GMPLS island may be changed without requiring end-to-
end action.
5.3.3. Contiguous LSPs
An end-to-end LSP crossing all three islands in the MPLS-GMPLS-
MPLS scenario could be provisioned as a single contiguous LSP
without the use of nesting or stitching. In this case, the
island border LSRs must perform the necessary MPLS to GMPLS
translation of the signaling messages. Specifically, they need
to make sure that signaling messages sent into the GMPLS island
contain GMPLS-format signaling objects, while messages sent into
an MPLS island are limited to the MPLS RSVP-TE format.
For the MPLS-GMPLS-MPLS scenario, this requirement is to:
- Map between Label Request and Generalized Label Request
- Map between Label and Generalized Label
- Introduce new objects when crossing into the GMPLS island
where necessary for the successful operation of the GMPLS
segment of the LSP. For example, to achieve alarm-free setup or
teardown of the LSP.
- Terminate GMPLS functionality at the edges of the GMPLS island,
for example by correctly reflecting the Administrative Status
object.
- When the LSP setup reaches the egress from the GMPLS island we
must try to map to MPLS-only objects. If this makes the LSP
setup impossible, the setup must fail.
Contiguous LSPs require less signaling state in the network than
stitched LSPs (see above) and can be set up with a single
signaling message exchange (that is, without pausing to set up
the central stitching segment).
6. Required mechanisms for other migration models
The required mechanisms for other migration models are for
future study.
7. 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
Expires January 2006 [Page 13]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
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
either fully MPLS or fully GMPLS, there are no changes necessary
to the security procedures.
8. IANA Considerations
There are no IANA actions required by this draft.
9. Acknowledgments
The authors are grateful to Adrian Farrel for his numerous
valuable comments.
10. References
10.1. Normative references
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[2] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471, January
2003.
[3] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[4] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[5] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", RFC
3784, June 2004.
[6] Mannie, E., "Generalized Multi-Protocol Label Switching
Architecture", RFC 3945, October 2004.
10.2. Informative references
[7] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering (RSVP-
TE)", RFC 3477, January 2003.
[8] Lang, J., "RSVP-TE Extensions in support of End-to-End
GMPLS-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-
signaling, work in progress.
Expires January 2006 [Page 14]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
[9] Kompella, K. and Y. Rekhter, "Routing Extensions in Support
of Generalized Multi-Protocol Label Switching", draft-ietf-
ccamp-gmpls-routing, work in progress.
[10] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching", draft-ietf-
ccamp-ospf-gmpls-extensions, work in progress.
[11] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support
of Generalized MPLS", draft-ietf-isis-gmpls-extensions, work
in progress.
[12] Lang, J., "Link Management Protocol (LMP)", Internet-Draft,
draft-ietf-ccamp-lmp, work in progress.
[13] Bryant, S. and P. Pate, "PWE3 Architecture", Internet-Draft,
draft-ietf-pwe3-arch, work in progress.
[15] Shiomoto, K., "Requirements for GMPLS-based multi-region
networks", draft-shiomoto-ccamp-gmpls-mrn-reqs, work in
progress.
[16] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Protocol Extensions for Multi-Region
Networks (MRN)", draft-papadimitriou-ccamp-gmpls-mrn-
extensions, work in progress.
[17] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions
to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[18] Berger, L., "GMPLS Based Segment Recovery", draft-ietf-
ccamp-gmpls-segment-recovery, work in progress.
[19] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in
progress.
[20] Ayyangar, A. and J. Vasseur, "Inter domain MPLS Traffic
Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-
domain-rsvp-te, work in progress.
[21] Farrel, A., "A Framework for Inter-Domain MPLS Traffic
Engineering", draft-ietf-ccamp-inter-domain-framework, work
in progress.
[22] Ali, Z., "Graceful Shutdown in MPLS Traffic Engineering
Networks", draft-ali-ccamp-mpls-graceful-shutdown, work in
progress.
[23] Shiomoto, K., "Multi-area multi-layer traffic engineering
using hierarchical LSPs in GMPLS networks", draft-shiomoto-
multiarea-te, work in progress.
[24] Le Roux, J., "Requirements for Inter-area MPLS Traffic
Engineering", RFC 4105, June 2005.
[25] Vasseur, J.P., Le Roux, J.L., "Routing extensions for
discovery of Traffic Engineering Node Capabilities", draft-
vasseur-ccamp-te-node-cap, work in progress.
[26] Vasseur, JP (Ed.), "A Per-domain path computation method
for computing Inter-domain Traffic Engineering (TE) Label
Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-path-
comp, work in progress.
Expires January 2006 [Page 15]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
[27] Farrel, A., Vasseur, JP., and Ash, G., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture,
work in progress.
[28] Ayyangar, A., and Vasseur, JP., "Label Switched Path
Stitching with Generalized MPLS Traffic Engineering", draft-
ietf-ccamp-lsp-stitching, work in progress.
11. Authors' Addresses
Deborah Brungard
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 420 1573
Email: dbrungard@att.com
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
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Phone: +81 422 59 3441
Email: oki.eiji@lab.ntt.co.jp
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240 8491
Email: dimitri.papadimitriou@alcatel.be
Daisaku Shimazaki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Phone: +81 422 59 4343
Email: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Phone: +81 422 59 4402
Email: shiomoto.kohei@lab.ntt.co.jp
12. Intellectual Property Statement
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.
Expires January 2006 [Page 16]
draft-oki-ccamp-gmpls-ip-interworking-06.txt July 2005
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.
13. Disclaimer of Validity
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.
14. Copyright Statement
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Expires January 2006 [Page 17]
