CCAMP Working Group Deborah Brungard (AT&T)
Internet Draft Jean-Louis Le Roux (France Telecom)
Expiration Date: December 2004 Eiji Oki (NTT)
Dimitri Papadimitriou (Alcatel)
Daisaku Shimazaki (NTT)
Kohei Shiomoto (NTT)
July 2004
Migrating from IP/MPLS to GMPLS networks
draft-oki-ccamp-gmpls-ip-interworking-03.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
[Page 1]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
Abstract
This document is addressing the migration from Multi-protocol label
switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to
expand the capacity of the existing MPLS-based infrastructure network,
the optical network consisting of L2SC, TDM, LSC, and FSC devices will
be deployed, which is controlled by the GMPLS protocols. GMPLS protocols
are, however, subtly different from MPLS protocols. In this document we
describe possible migration scenarii, the mechanisms to compensate the
difference between MPLS and GMPLS protocols, and how the mechanisms are
applied to migrate from the MPLS to the GMPLS network.
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.
1. Introduction
Multi-protocol label switching (MPLS) is widely deployed with applica-
tions such as traffic engineering and virtual private network (VPN).
Various kinds of services such as VoIP, IPv6, L2VPN/L3VPN, pseudo wire
emulation are expected to be converged over the MPLS-based infrastruc-
ture network.
Traffic volume is tremendously increasing as broadband service enabled
by ADSL and FTTH is rapidly penetrating the market and the processing
performance of terminal and server is ever increasing. In order to cope
with such increase of the traffic volume, optical networks, which con-
sists of L2SC, TDM, LSC, and FSC devices, will be introduced.
Generalized MPLS (GMPLS) is being standardized by extending MPLS to con-
trol such optical networks (see [RFC3471], [RFC3473], [GMPLS-ROUTING],
[GMPLS-OSPF], [GMPLS-ISIS], [GMPLS-LMP]). GMPLS network will be deployed
as a part of the existing MPLS infractructure. MPLS and GMPLS devices
will coexist in the network until the existing MPLS network is com-
pletely migrated to the GMPLS network.
GMPLS protocols are, however, subtly extending MPLS protocols' capabili-
ties. In order to migrate from the existing MPLS to the GMPLS network,
we need to define mechanisms to compensate the difference between MPLS
[Page 2]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
and GMPLS. In this document we discuss the migration scenarii from MPLS
to GMPLS networks, the mechanisms to compensate the difference between
MPLS and GMPLS, and the applicability of the mechanisms to the possible
migration scenarii.
We should note that GMPLS covers Packet Switching Capable (PSC) networks
[GMPLS-ARCH]. In the rest of this document, when dealing with GMPLS, it
means both PSC and non-PSC. Otherwise PSC GMPLS or non-PSC GMPLS is
explicitly mentioned.
GMPLS introduces new features such as bidirectional LSPs, label sugges-
tion, label restriction, graceful restart, graceful teardown, and for-
warding adjacencies (see [GMPLS-ARCH]). Also several features are pro-
vided in a distinct manner. For instance local protection is provided
using distinct mechanisms in MPLS (see [MPLS-FRR]) and GMPLS (see
[GMPLS-SR]). Migration from MPLS to GMPLS should bring these features
and such distinct mechanisms in the existing MPLS-based infrastructure
network.
The rest of this document is organized as follows. In Section 2, we
taxonomize the migration scenarii from MPLS to GMPLS networks. In Sec-
tion 3, we describe the problems caused by the difference between MPLS
and GMPLS protocols. In Section 4, we present the required mechanisms,
which bridge the difference between MPLS and GMPLS protocols. Some of
those mechanisms are available today and others are not. In Section 5,
we present the applicability of the required mechanisms to a reference
network model for the migration from MPLS to GMPLS networks.
2. Migration scenarii
Two categories of migration scenarii are considered: (1) MPLS-GMPLS-MPLS
and (2) GMPLS-MPLS-GMPLS. In case of (1) MPLS-GMPLS-MPLS scenario,
source and destination nodes of the Label Switched path (LSP) are in
MPLS and a set of its intermediate nodes take part of GMPLS. In case of
(2) GMPLS-MPLS-GMPLS scenario, LSP source and destination nodes are in
GMPLS network and a set of its intermediate nodes take part of MPLS net-
work. Each category is subdivided in two sub-categories as to whether
GMPLS is PSC or non-PSC.
MPLS-GMPLS (PSC) migration scenario, where LSP start/end in an MPLS net-
work and end/start in a GMPLS PSC network, will be addressed in a future
revision.
[Page 3]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
2.1. MPLS-GMPLS(non-PSC)-MPLS
Introduction of a GMPLS-based optical core network to increase the
capacity is an example of this category. TDM, LSC, and/or FSC LSPs are
established between MPLS networks across the GMPLS network. A set of
those LSPs provide virtual network topology for MPLS networks. This
topology may be reconfigurable by adding and/or removing those LSPs
[MRN]. MPLS LSRs and subnetworks interconnected at the edges of the vir-
tual network topology may form a single MPLS network.
Figure 1 shows the reference network model for the MPLS-GMPLS(non-
PSC)-MPLS migration. The reference network model consists of three
regions: ingress, transit, and egress. Both the ingress and egress
regions are MPLS-based while the transit region is GMPLS-based. The
nodes at the boundary of the MPLS and GMPLS regions (G1, G2, G5, and G6)
are referred to as "border node" hereafter. All nodes except the border
nodes in the GMPLS-based transit region (G3 and G4) are non-PSC device,
i.e., optical equipment (TDM, LSC, and FSC). An MPLS LSP can be provi-
sioned from a node in the ingress MPLS-based region (say, R2) to a node
in the egress MPLS-based region (say, R4). The LSP is referred to as
the "e2e" LSP hereafter. The switching capability of both end points of
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 1 MPLS-GMPLS(non-PSC)-MPLS migration model.
[Page 4]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
2.2. MPLS-GMPLS(PSC)-MPLS
MPLS-based converged network can be migrated to GMPLS (PSC)-based con-
verged network. The rationale of this type of migration scenario is
supported by two factors: (1) GMPLS-based advanced feature, (2) stepwise
migration for the GMPLS-based optical core network. Regarding the
GMPLS-based advanced feature, numerous features are being developed in
GMPLS context (and MPLS) including bi-directional LSP, label control,
graceful restart, graceful teardown and forwarding adjacencies. Exist-
ing MPLS-based converged network could be migrated to GMPLS (PSC)-based
converged network to deliver the advanced features. Once the PSC network
is migrated to GMPLS-based one, it could be migrated to GMPLS-based
optical core network with less effort.
2.3. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC)
In this scenario, TDM, L2SC e2e LSPs are provisioned in the GMPLS net-
work, which is partly disconnected. In case the MPLS-based infrastruc-
ture network is widely deployed, it is used to bridge the disconnected
GMPLS networks. Moreover, pseudo wire emulation is used edge-to-edge in
the MPLS-based converged network to carry those LSPs [PWE3].
Figure 2 shows the reference network model for the GMPLS(non-PSC)-MPLS-
GMPLS(non-PSC) migration. The reference network model consists of three
regions: ingress, transit, and egress. Both the ingress and egress
regions are GMPLS-based while the transit region is MPLS-based. The
nodes at the boundary of the MPLS and GMPLS regions (G3, G4, G5, and G6)
are referred to as "border node" hereafter. All nodes except the border
nodes in the GMPLS-based regions (G1, G11, G2, G21, G71, G7, G81, and
G8) are non-PSC devices. A GMPLS LSP can be provisioned from a node in
the ingress GMPLS-based region (say, G2) to a node in the egress GMPLS-
based region (say, G8). The LSP is referred to as the "e2e" LSP here-
after. The switching capability of both end points of e2e LSP must be
the same.
[Page 5]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
.................. ............................. ..................
: GMPLS(non-PSC) : : MPLS : : GMPLS(non-PSC) :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|G1 |__|G11|___|G3 |__________|R1 |__________|G5 |___|G71|__|G7 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|G2 |__|G21|___|G4 |__________|R2 |__________|G6 |___|G81|__|G8 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<-------------------------------------------------------->|
e2e LSP
Figure 2 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration model.
2.4. GMPLS(PSC)-MPLS-GMPLS(PSC)
In this scenario, GMPLS PSC e2e LSPs are provisioned in the GMPLS net-
work, which is partly disconnected. In case the MPLS-based infrastruc-
ture network is widely deployed, it is used to bridge the disconnected
GMPLS networks. Since MPLS-based network is PSC, the GMPLS PSC LSP can
cross MPLS-based converged network without extra treatment in data
plane.
3. Difference between MPLS and GMPLS protocols
3.1. Routing
In this document we assume that the OSPF-TE is used as IGP-TE. However
the IGP-TE description should apply to both IS-IS and OSPF. Specifics
concerning IS-IS will be detailed in the next release of this document.
TE-link information is advertised in link state advertisement. It
allows collecting the whole topology information, which is stored in
traffic-engineering data base (TEDB). Best-effort route and/or traffic-
engineered explicit route for the destination are calculated using the
TEDB.
[Page 6]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
GMPLS extends the set of sub-TLVs for TE-link advertisements. Non-PSC
TE-link information used in GMPLS is not supported by MPLS. Even PSC TE-
link information used in GMPLS is not fully supported by MPLS (this is
particularly the case for the Interface Switching Capability Descriptor
sub-TLV). As a result, one cannot compute traffic-engineered explicit
route if they are travelling through both MPLS and GMPLS regions.
Figure 3 illustrates the problem of mismatch of TE-link information in
MPLS and GMPLS. Suppose that an e2e LSP is provisioned between R2 and
R4 and that we need to compute the path between R2 and R4 (say,
R2-R21-G2-G4-G6-R41-R4). The TE link information for the links R2-R21,
R21-G2, G6-R41 and R41-R4 is MPLS-based TE link LSA, while the ones for
the links G2-G4 and G4-G6 is GMPLS-based. The node in MPLS-based
ingress region (say, R2) cannot compute the path, which consists of mix-
ture of MPLS-based and GMPLS-based TE link 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 3 Problem mismatch of TE-link information in MPLS and GMPLS
Except for Opaque-LSA associated with TE-link, MPLS and GMPLS use the
same set of LSAs, e.g., router-LSA, network-LSA, summary-LSA and etc.
These LSAs in GMPLS network construct the topology database of the con-
trol plane of GMPLS network.
3.2. Signaling
GMPLS RSVP-TE signalling ([RFC 3473]) introduces new objects, and their
associated procedures, that can not be processed/inserted by MPLS LSRs:
[Page 7]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
- The (Generalized) Label Request object (new C-Type), used to iden-
tify the LSP encoding type, the switching type and the generalized
protocol ID (G-PID) associated with the LSP.
- The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID
ERO/RRO subobjects that handle the Control plane/Data plane separa-
tion in GMPLS network.
- The Suggested Label Object, used to reduce LSP setup delays.
- The Label Set Object, used to restrict label allocation to a set of
label, which (particularly useful for wavelength conversion inca-
pable nodes)
- The Upstream Label Object, used for bidirectional LSP setup (see
also 3.4)
- The Restart Cap object, used for graceful restart.
- The Admin Status object, used for LSP administration, and particu-
larly for graceful LSP teardown.
3.3. Control plane/data plane separation
TDM, LSC, FSC networks do not recognize packet delineation. In GMPLS,
the control channel can be logically (in-band) or physically (out-of-
band) separated from the data channel in those networks. The control
channels between adjacent nodes constitute a control plane network. Con-
trol packets of routing and signaling protocols are transmitted over the
control plane network.
If the GMPLS network consists of only PSC devices, there can be no con-
trol plane/data plane separation. All control packets share the same
network links with data packets. If the GMPLS network consists of non-
PSC devices, there is at least a logical C/D separation at least between
PSC device and non-PSC device in GMPLS networks and between non-PSC and
non-PSC devices.
The GMPLS control plane, which is designed to carry the control packet
in GMPLS network, is not likely to have enough capacity to carry the
user-data traffic from MPLS network. Therefore, the control plane must
ensure is it not carrying data traffic from the MPLS network (see
[GMPLS-ROUTING]).
[Page 8]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
3.4. Bi-directional LSP
Since GMPLS supports TDM, LSC, and FSC switching and LSP classes, which
are mainly bi-directional channels, it also provides bi-directional LSP
setup. In a single signaling session, bi-directional LSPs can be created
along the same route in GMPLS network. On the other hand, there is no
equivalent mechanism to support bi-directional LSPs in MPLS network. The
forward and backward LSPs are created in different signaling sessions.
The route taken by those LSPs may be different from each other. Their
sessions are treated differently from each other.
If MPLS and GMPLS networks are inter-connected, the bi-directional LSPs
from GMPLS network need to be carried in MPLS network, which does not
support bi-directional LSP setup. At least we need a mechanism allowing
to route the forward and backward LSPs on the same route.
4. Required mechanism
In this section, we present at set of routing and signalling mechanisms,
in order to bridge the difference between MPLS and GMPLS protocols.
This section only proposes mechanisms for MPLS-GMPLS-MPLS migration.
GMPLS-MPLS-GMPLS (using PWE3 stuff) is for further study.
4.1. Routing
The entire network consisiting of ingress, transit, and egress regions
(See Fig.1 or 2 for instance) may be either single-area or multi-area
from the IGP perspective.
4.1.1. Single-area
If the entire network is a single-area, the partial topology of GMPLS-
based region, which is consisting of PSC-link, should be visible to MPLS
regions. GMPLS TE-links are advertised as MPLS TE-links using MPLS-
based TE link information to the MPLS networks so that node in the MPLS
region can understand the GMPLS TE-links. This requires some TE-link
[Page 9]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
information conversion.
If the GMPLS-based region consists of only non-PSC devices except the
border nodes, PSC-links should be set up between the border nodes. For
example, in Fig. 3, a PSC-link can be set up between G2 and G6. PSC-
links are advertised as the forwarding adjacency (FA) in the GMPLS-
based region. The e2e LSP can be tunnelled through the FA [HIER]. In
the MPLS to GMPLS migration scenarii, FA should be advertised as TE-
links in the MPLS regions, using MPLS-based TE-link information.
A set of FAs across the GMPLS region provides the virtual network topol-
ogy (VNT), which can be reconfigured by creating and/or destroying FAs,
to MPLS regions. See [MRN] for details.
MPLS TE-links MAY be understood by the nodes in the GMPLS network, which
can transform MPLS-based TE-link information into GMPLS-based TE-link
information.
4.1.1.1. Virtual FA
If the entire network consists of a single IGP area and the GMPLS-based
region consists of only non-PSC devices except the border nodes, FAs
should be set up between the GMPLS border nodes. To avoid unnecessary
bandwidth consumption non-PSC FA LSP should be created only if there
exists traffic demand between the end points.
In order to compute the path across the GMPLS region, the FA-LSP must be
set up for being advertized as per [HIER]. The "virtual" FA-LSP is
defined here to cope with the situation. The virtual FA-LSP is not
instantiated but is advertised as a TE-link by routing protocol to
attract traffic. The virtual FA may be provisioned using the similar
method for provisioning the secondary LSP in the shared mesh restoration
scheme [P&R]. Or the virtual FA may be just signalled between both end
points without having the transit nodes intervene.
A set of virtual FAs forms the virtual topology for the best-effort
and/or the traffic-engineered route across the GMPLS region. The virtual
topology may be designed taking into account the (forecast) traffic
demand and the available resource in the transit region. The virtual
topology may dynamically change according to the variation of the (fore-
cast) traffic demand and the available resource in the transit region to
optimize the tradeoff between network performance and the residual net-
work capacity. How to design the virtual topology and its changes is out
of scope of this document.
The virtual topology is changed by setting up and/or tearing down
[Page 10]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
virtual FA-LSP. Signaling messages are used to exchange the link iden-
tifiers in a similar way of the FA as described in [RFC3477] and [LSP-
HIER]. Unlike the case of FA-LSP, the intermediate nodes may not be
involved in signaling message processing when the virtual FA-LSP is not
provisioned (Just link interface identifiers are exchanged by signaling
between ingress and egress nodes). Both unnumbered and numbered virtual
FAs should be defined.
There is no routing adjacency along the (virtual) FA. There is no hello
packets exchanged between the end points of the (virtual) FA.
When an e2e MPLS LSP is setup through a virtual FA, this should trigger
the setup of a real FA-LSP is the GMPLS network.
4.1.2. Multi-area
A simple migration approach can also consist in separating MPLS and
GMPLS networks into distinct IGP areas, and then rely on multi-area
routing, path computation, and signaling solutions under specification
in CCAMP WG (ABR acting as a Path Computation Element for instance).
Basicaly there is no backward compatibility issue when MPLS and GMPLS
LSRs resides in disctinct IGP areas, as TE-link information is not
leaked across area (see see [INTER-AREA-REQ] and [INTER-Domain]).
4.2. Signaling
We describe the signaling mechanisms, which can be applied to the migra-
tion scenarii from MPLS to GMPLS. Three basic cases for the MPLS-GMPLS-
MPLS environment are described in Fig. 4: LSP nesting, LSP converting,
and LSP stitching.
LSP nesting: One or more packet LSPs is nested into one LSP.
LSP converting: The end-to-end packet LSP signaling messages (RFC 3209)
is translated at the GMPLS borders into GMPLS RSVP-TE (see RFC 3473).
The GMPLS RSVP-TE segment MUST also be PSC. This case requires a ser-
vice interworking function 3209/3473 (at the control plane level).
LSP stitching: A segment PSC LSP is stitched within an end-to-end packet
LSP. This case does require a network interworking function (at the
control plane level) since MPLS signaling messages are directed between
GMPLS border nodes.
[Page 11]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
................. .............................. ..................
: MPLS : : GMPLS (PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
session for e2e LSPs
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
session for FA/LSP tunnel
|<-------------------------->|
e2e LSP _____________________________
<------------ | FA/LSP tunnel | ----------->
<------------ | | ----------->
<------------ | | ----------->
|_____________________________|
(a) LSP nesting
e2e session
|<-------------------------------------------------------->|
____________ ____________________________ ____________
| MPLS seg. || GMPLS segment || MPLS seg. |
|____________||____________________________||____________|
(b) LSP converting
e2e session
|<-------------------------------------------------------->|
transit session
|<-------------------------->|
____________ ____________________________ ____________
| MPLS seg. || GMPLS segment || MPLS seg. |
|____________||____________________________||____________|
(c) LSP stitching
Figure 4 Comparisons of signaling in MPLS-GMPLS-MPLS migration model.
[Page 12]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
4.2.1. LSP nesting
Figure 4 (a) illustrates the LSP nesting in the MPLS-GMPLS-MPLS refer-
ence network model. An FA-LSP is created by setting up the FA-LSP. FA
is established between the boundary of the ingress and the transit
regions and that of the transit and the egress regions. Three e2e LSPs
are provisioned between the nodes in the MPLS-based ingress region (say,
R2) and egress region (say, R4). These e2e LSPs are tunnelled inside
the same FA-LSP across the transit region.
LSP nesting is different from the LSP stitching and the LSP converting
with respect to data plane. The e2e LSP is nested inside the FA while
there is no nesting in the LSP stitching and the LSP converting. Multi-
ple e2e LSPs can be nested inside a single FA-LSP. Scalability is
hereby attained.
There exist at least two sessions: one for the FA-LSP and the others for
e2e LSP(s). Along the FA-LSP, the state is created and maintained dur-
ing the life-time of the FA-LSP. When the FA-LSP is re-routed (for
example due to re-optimization, failure recovery, etc.), the FA link is
not impacted as long as the alternative FA-LSP exists.
FA-LSP mechanism applies to MPLS-GMPLS (non PSC)-MPLS and MPLS-GMPLS
(PSC)-MPLS migration scenarii.
4.2.2. LSP converting
LSP can be converted from MPLS to GMPLS and vice versa at the boundary
of MPLS and GMPLS regions while remaining in the same session. This is
achieved by delivering an interworking function at the control plane of
the GMPLS border nodes. Figure 4 (b) illustrates the LSP converting in
the MPLS-GMPLS-MPLS reference network model. The e2e LSP is provisioned
between the nodes in the MPLS-based ingress region (say, R2) and egress
region (say, R4). The e2e LSP consists of three segments: ingress,
transit, egress. The transit segment is GMPLS-based and therefore it is
referred to as GMPLS-segment while others are referred to as MPLS-seg-
ments. The e2e LSP is associated with the single session, which is
referred to as the "e2e" session. This is relevant only for MPLS-GMPLS
(PSC)-MPLS migration scenario.
4.2.2.1. MPLS->GMPLS
LSP is converted from MPLS to GMPLS at the boundary of MPLS ingress and
GMPLS transit regions. In case of C/D separation in the GMPLS transit
[Page 13]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
region, the signaling message is separated from the data plane network
at the boundary.
Regarding the control plane, the signaling message associated with the
e2e LSP is carried in the control plane network in the GMPLS transit
region. Appropriate objects newly defined for GMPLS (say, Generalized
label request object) is attached to the signaling message.
4.2.2.2. GMPLS->MPLS
LSP is converted from GMPLS to MPLS at the boundary of GMPLS transit and
MPLS egress regions. In case of C/D separation in the GMPLS transit
region, the signaling message from the data plane network is multiplexed
to the data plane message at the boundary. LSP is converted with
respect to both the control and the data plane aspects.
Regarding the control plane aspect, the signaling message objects, which
are not supported by MPLS, are lost. The associated functions are not,
therefore, effective in MPLS network accordingly. GMPLS-segment is
either uni-directional or bi-directional. There is no mechanism to set
up the bi-directional MPLS LSPs within the same session along the same
route.
4.2.2.3. ERO/RRO processing
There are three cases depending on the level of detail of the transit
segment specified as part of the EROs issued in the Path message issued
by the ingress of the e2e LSP.
1) The ERO issued by the ingress of the e2e LSP includes the tail-end
of the transit segment as a strict subobject. Then, if the head-
end of the transit segment is also included as a strict node, in
this case ERO processing follows rules described in Section 8.2 of
[LSP-HIER] as the sequence of the transit segment is complete once
issued by the ingress of the e2e LSP. Otherwise, if the head-end
node of the transit segment (or any other subobject preceding the
tail-end) is specified as a loose subobject, the preceding strict
node inserts the sequence of subobjects within the ERO as specified
in [RFC 3209] to reach the next loose node.
[Page 14]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
2) The ERO issued by the ingress of the e2e LSP includes both head-
(strict or loose) and tail-end (loose) of the transit segment. In
this case, the ingress GMPLS border node inserts sequence of subob-
jects within the ERO as specified in [RFC 3209] to reach the egress
border node.
3) The ERO issued by the ingress of the e2e LSP does not include the
tail-end of the transit segment. In this case, the ingress border
node should decide the exit point to reach the next loose node
being outside of the transit region.
RROs in the transit segment may carry the nodes in the transit region.
The nodes in the transit segment may be removed from the RROs when they
depart from the transit region. The ingress and egress border nodes
should be included in the RROs when they are carried in the ingress and
the egress regions.
4.2.3. LSP stitching
LSP can be stitched at the boundary of MPLS and GMPLS regions [Inter-
domain]. The LSP stretches from the ingress through the transit to the
egress regions. Figure 4 (c) illustrates the LSP stitching in the MPLS-
GMPLS-MPLS reference network model. The e2e LSP is provisioned between
the nodes in the MPLS-based ingress region (say, R2) and egress region
(say, R4). The e2e LSP consists of two segments: ingress/egress and
transit. The transit segment is GMPLS-based and therefore it is
referred to as GMPLS-segment while others are referred to as MPLS-seg-
ments. The e2e LSP is associated with the two sessions: one for the
entire stretch (i.e., ingress to egress regions) and the other for the
transit segment. The signaling mechanisms described in [INTER-DOMAIN-
SIG] can be applied.
4.2.4. Discovery of GMPLS signalling capability
I may be useful to advertise into the IGP the capability of a node to
support GMPLS signalling. This would allow every node in the network to
automatically discover the GMPLS signalling regions. [TE-INFO] provides
a functional description of routing extensions in order to advertise TE
router information, including Control Plane Capabilities such as GMPLS
signaling.
[Page 15]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
5. MPLS-GMPLS-MPLS reference model
In this section, the required mechanisms with the MPLS-GMPLS-MPLS refer-
ence network model is discussed. FA/LSP tunnel, LSP converting, and LSP
stiching are applied to the reference network model.
From Figure 1, we consider that the packet LSP is set up between the
ingress and the egress regions. The LSP is referred to as "e2e" LSP
hereafter. The LSP portion corresponding to the transit GMPLS-base
region is referred to as "transit segment". The transit segment is
implemented by either (1) LSP nesting, (2) LSP converting, or (3) LSP
stitching.
5.1. LSP nesting
5.1.1. Basic description
FAs are created between the GMPLS border nodes. The FAs are advertised
in the MPLS regions, by the routing protocol, using MPLS TE-link infor-
mation ([OSPF-TE] or [ISIS-TE]).
The e2e LSP is tunneled through the FA across the GMPLS-based transit
region. Multiple e2e LSPs may be tunnelled through a single FA. The e2e
LSP may be carried over multiple hops of FAs across the GMPLS-based
transit region unless there is no direct FA between the ingress and the
egress regions.
5.1.2. Traffic demand change
Traffic demand may change after the FA is created. Some FAs, which do
not carry any e2e LSP any longer may be released for resource release.
They may be also retained for future usage. Release or retention of
underutilized FAs is a policy decision. Detail of the policy is out of
scope of this document.
FAs may be created based on the policy, which might consider residual
resource in GMPLS-based transit region and the change of traffic demand.
By creating the new FAs, the network performance such as maximum resid-
ual capacity may be improved.
As the number of FAs grows, the residual resource in the GMPLS-based
transit region may decrease. In this case, re-optimization may be
invoked in the GMPLS-based transit region according the the policy.
[Page 16]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
Detail of the policy is again out of scope of this document.
As part of the reoptimization process, FA-LSPs may be rerouted while
keeping interface identifiers of FA links unchanged. However, the rout-
ing in MPLS level should be unaffected since there is no change of
topology composed of FAs across the GMPLS-based transit region.
When residual resource in the GMPLS-based transit region decreases, some
FAs may be released according to the policy. Detail of the policy is
again out of scope of this document. The FA should be released only
after the LSA associated with the FA is deleted throughout the network.
Once the LSA is deleted, the e2e LSPs routed over the FA are expected to
get rerouted around the FA.
5.1.3. Nest of FAs
E2e LSP can be tunneled into the PSC or non-PSC FA LSPs established
between GMPLS border nodes. Further nesting can also occur within the
GMPLS network (see [LSP-HIER]).
Full mesh of PSC FA-LSPs may be created between every border nodes using
a set of non-PSC FA-LSPs across the GMPLS-based transit region [MAMLTE].
The merit of this mechanism is to attain the stability of MPLS-level
routing, i.e., the forwarding table of the LSR is kept intact even if
the topology composed of a set of non-PSC FA-LSPs are modified. There
is not topology change from the view point of MPLS-level. Traffic engi-
neering is performed by reconfiguring the virtual topology consisting of
a set of non-PSC FAs across the GMPLS-based transit region. Thanks to
statistical multiplexing gain, there is no waste of bandwidth resource
even if a PSC FA-LSP is created.
5.1.4. Virtual FA
The virtual FA can be used instead of the FA to allow the path across
the GMPLS-based transit region to be computed while avoiding waste of
bandwidth and adaptation port occupation by non-PSC FA.
A set of the virtual FAs forms the virtual topology for the best-effort
and/or the traffic-engineered route across the GMPLS-based transit
region. The virtual topology may be designed taking into account the
(forecast) traffic demand and available resource in the GMPLS-based
transit region. How to design the virtual topology is out of scope of
[Page 17]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
this document.
The virtual topology may dynamically change according to the change of
the (forecast) traffic demand and the available resource in the transit
region. The virtual topology is changed by setting up and/or tearing
down the virtual FA.
5.2. LSP converting/LSP stitching
5.2.1. One-to-one relationship
LSP converting and LSP stitching have common property when they are
applied to the reference model for MPLS-GMPLS-MPLS. There is a one-to-
one relationship between the e2e LSP and the transit segment. When the
e2e LSP is set up and/or torn down, the associated transit segment is
set up and/or torn down accordingly.
Due to the one-to-one relationship, these mechanisms are relevant only
for MPLS - GMPLS (PSC) -MPLS scenario.
5.2.2. Traffic demand change
When the traffic demand for the e2e LSP changes, the bandwidth allocated
to the transit segment may be modified. When the bandwidth is modified
in the SENDER_TSPEC/FLOWSPEC object, the LSP-ID field of SENDER_TEMPLATE
object for the e2e LSP is modified in both methods (make-before-break,
see [RFC3209]). This modification may trigger the same LSP ID change
for the transit segment if its bandwidth needs to be readjusted.
6. Acknowledgements
The authors are grateful to Adrian Farrel for his numerous valuable com-
ments.
[Page 18]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
7. Security Considerations
There are not security issues in this draft.
8. References
8.1. Normative references
[RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional
Description", RFC 3471, January 2003.
[RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE Exten-
sions", RFC 3473, January 2003.
[GMPLS-ARCH] E. Mannie (Editor), "Generalized Multi-Protocol Label
Switching Architecture," <draft-ietf-ccamp-gmpls-architecture-07.txt>
(Work in progress), May 2003.
[GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS", <draft-ietf-ccamp-ospf-gmpls-extensions-12.txt> (work
in progress), October 2003.
[GMPLS-ISIS] "IS-IS extensions in support of generalized multi-protocol
label switching," <draft-ietf-isis-gmpls-extensions-19.txt> (work in
progress), October 2003.
[GMPLS-LMP] J. Land, "Link management protocol (LMP)," <draft-ietf-
ccamp-lmp-10.txt> (work in progress), October 2003.
[PWE3] S. Bryant, P. Pate (Editors), "PWE3 Architecture," <draft-ietf-
pwe3-arch-07.txt> (work in progress), March 2003.
[OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF] J. Moy, "OSPF Version 2", RFC2328, April 1998.
[Page 19]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
8.2. Informative references
[MRN] D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard. J.L. Le
Roux, "Generalized MPLS Architecture for Multi-Region Networks," <draft-
vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt> (work in progress), February
2004.
[GMPLS-ROUTING] K. Kompella and Y. Rekhter, "Routing Extensions in Sup-
port of Generalized Multi-Protocol Label Switching," <draft-ietf-ccamp-
gmpls-routing-09.txt> (work in progress), October 2003.
[Inter-domain] A. Farrel, J-P. Vasseur, and A. Ayyangar, "A framework
for inter-domain MPLS traffic engineering," <draft-farrel-ccamp-inter-
domain-framework-00.txt>
(work in progress), April 2004.
[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS
TE," <draft-ietf-mpls-lsp-hierarchy-08.txt> (work in progress), Septem-
ber 2002.
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC3477,
January, 2003.
[MAMLTE] K. Shiomoto et al., "Multi-area multi-layer traffic engineering
using hierarchical LSPs in GMPLS networks," <draft-shiomoto-multiarea-
te-01.txt> (work in progress), June 2002.
[P&R] J.P. Lang, Y. Rekhter, D. Papadimitriou (Editors), "RSVP-TE
Extensions in support of End-to-End GMPLS-based Recovery", <draft-ietf-
ccamp-gmpls-recovery-e2e-signaling-01.txt> (work in progress), May 2004.
[GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the Overlay
Model," <draft-ietf-ccamp-gmpls-overlay-04.txt> (work in progress),
April 2004.
[GMPLS-RECOVERY] CCAMP P&R Design Team, "Analysis of Generalized Multi-
Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including
Protection and Restoration)," <draft-ietf-ccamp-gmpls-recovery-analy-
sis-03.txt> (work in Progress), April 2004.
[TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions for
discovery of TE router information", <draft-vasseur-ccamp-te-router-
info-00.txt> (work in progress), July 2004.
[INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS traffic
engineering RSVP extensions", <draft-ayyangar-ccamp-inter-domain-rsvp-
[Page 20]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
te-00.txt> (work in progress), July 2004.
[MPLS-FRR] Ping Pan et. at., "Fast reroute extensions to RSVP-TE for LSP
tunnels," <draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. (work in
progress), May 2004.
[GMPLS-SR] Louis Berger, Igor Bryskin, Dimitri Papadimitriou, Adrian
Farrel, "GMPLS Based Segment Recovery,"<draft-ietf-ccamp-gmpls-segment-
recovery-00.txt> (work in progress), March 2004.
[INTER-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements
for Inter-Area MPLS Traffic Engineering", <draft-ietf-tewg-interarea-
mpls-te-req-02.txt>, June 2004.
9. Author's Address
Deborah Brungard
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 420 1573
E-mail: dbrungard@att.com
Jean-Louis Le Roux
France Telecom R&D
av Pierre Marzin
22300 Lannion
France
E-mail: jeanlouis.leroux@francetelecom.com
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
E-mail: oki.eiji@lab.ntt.co.jp
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
E-mail: dimitri.papadimitriou@alcatel.be
Daisaku Shimazaki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
[Page 21]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
E-mail: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
E-mail: shiomoto.kohei@lab.ntt.co.jp
10. Intellectual Property Rights Notices
The IETF takes no position regarding the validity or scope of any intel-
lectual property 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; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made available for
publication 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 implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this stan-
dard. Please address the information to the IETF Executive Director.
10.1. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
[Page 22]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or ref-
erences to the Internet Society or other Internet organizations, except
as needed for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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 FIT-
NESS FOR A PARTICULAR PURPOSE.
[Page 23]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Conventions used in this document . . . . . . . . . . . . . . . . . 2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Migration scenarii . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. MPLS-GMPLS(non-PSC)-MPLS . . . . . . . . . . . . . . . . . . . 4
2.2. MPLS-GMPLS(PSC)-MPLS . . . . . . . . . . . . . . . . . . . . . 5
2.3. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) . . . . . . . . . . . . . . 5
2.4. GMPLS(PSC)-MPLS-GMPLS(PSC) . . . . . . . . . . . . . . . . . . 6
3. Difference between MPLS and GMPLS protocols . . . . . . . . . . . 6
3.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Control plane/data plane separation . . . . . . . . . . . . . 8
3.4. Bi-directional LSP . . . . . . . . . . . . . . . . . . . . . . 9
4. Required mechanism . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Single-area . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.1. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Multi-area . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. LSP nesting . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. LSP converting . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2.1. MPLS->GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2.2. GMPLS->MPLS . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2.3. ERO/RRO processing . . . . . . . . . . . . . . . . . . . . 14
4.2.3. LSP stitching . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.4. Discovery of GMPLS signalling capability . . . . . . . . . . 15
5. MPLS-GMPLS-MPLS reference model . . . . . . . . . . . . . . . . . 16
5.1. LSP nesting . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. Basic description . . . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Traffic demand change . . . . . . . . . . . . . . . . . . . . 16
5.1.3. Nest of FAs . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.4. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. LSP converting/LSP stitching . . . . . . . . . . . . . . . . . 18
5.2.1. LSP One-to-one relationship . . . . . . . . . . . . . . . . . 18
5.2.2. LSP Traffic demand change . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative references . . . . . . . . . . . . . . . . . . . . . 19
8.2. Informative references . . . . . . . . . . . . . . . . . . . . 20
9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Intellectual Property Rights Notices . . . . . . . . . . . . . . 22
10.1. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 22
[Page 1]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
[Page 2]
================================ TXT file end
================================
================================ NORFF file
begin=============================
.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF
.ds RF [Page %]
.ds CF
.ds LH E. Oki et al.
.ds RH July 2004
.ds CH draft-oki-ccamp-gmpls-ip-interworking-03.txt
.ad l
.in 0
.nh
.hy 0
.nf
CCAMP Working Group Deborah Brungard (AT&T)
Internet Draft Jean-Louis Le Roux (France Telecom)
Expiration Date: December 2004 Eiji Oki (NTT)
Dimitri Papadimitriou (Alcatel)
Daisaku Shimazaki (NTT)
Kohei Shiomoto (NTT)
July 2004
.ce
Migrating from IP/MPLS to GMPLS networks
.ce
draft-oki-ccamp-gmpls-ip-interworking-03.txt
.ti 0
Status of this Memo
.fi
.in 3
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.
.ti 0
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
.SH
Abstract
.XS
Abstract
.XE
This document is addressing the migration from Multi-protocol label
switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to
expand the capacity of the existing MPLS-based infrastructure network,
the optical network
consisting of L2SC, TDM, LSC, and FSC devices
will be deployed, which is controlled by the GMPLS protocols. GMPLS
protocols are, however,
subtly different from MPLS protocols. In this document we describe
possible migration scenarii,
the mechanisms to compensate the difference between MPLS and GMPLS
protocols, and how the mechanisms are applied to
migrate from the MPLS to the GMPLS network.
.SH
Conventions used in this document
.XS
Conventions used in this document
.XE
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.
.NH 1
Introduction
.XS
\*(SN Introduction
.XE
Multi-protocol label switching (MPLS) is widely deployed with
applications such as traffic
engineering and virtual private network (VPN). Various kinds of services
such as VoIP, IPv6,
L2VPN/L3VPN, pseudo wire emulation are expected to be converged over the
MPLS-based
infrastructure network.
Traffic volume is tremendously increasing as broadband service enabled
by ADSL and
FTTH is rapidly penetrating the market and the processing performance of
terminal and
server is ever increasing. In order to cope with such increase of the
traffic volume, optical networks, which consists of L2SC, TDM, LSC, and
FSC devices, will be
introduced.
Generalized MPLS (GMPLS) is being standardized by extending MPLS to
control such
optical networks (see [RFC3471], [RFC3473], [GMPLS-ROUTING],
[GMPLS-OSPF], [GMPLS-ISIS], [GMPLS-LMP]). GMPLS
network will be deployed as a part of the existing MPLS infractructure.
MPLS and GMPLS devices
will coexist in the network until the existing MPLS network is
completely migrated to the
GMPLS network.
GMPLS protocols are, however, subtly extending MPLS protocols'
capabilities. 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 scenarii from MPLS to GMPLS networks, the mechanisms to
compensate the
difference between MPLS and GMPLS, and the applicability of the
mechanisms to the
possible migration scenarii.
We should note that GMPLS covers Packet Switching Capable (PSC) networks
[GMPLS-ARCH].
In the rest of this document, when dealing with GMPLS, it means both PSC
and non-PSC.
Otherwise PSC GMPLS or non-PSC GMPLS is explicitly mentioned.
GMPLS introduces new features such as bidirectional LSPs, label
suggestion, label restriction, graceful restart, graceful teardown, and
forwarding adjacencies (see [GMPLS-ARCH]).
Also several features are provided in a distinct manner. For instance
local protection is provided using distinct mechanisms in MPLS (see
[MPLS-FRR]) and GMPLS (see [GMPLS-SR]).
Migration from MPLS to GMPLS should bring these features and such
distinct mechanisms in the existing MPLS-based infrastructure network.
The rest of this document is organized as follows.
In Section 2, we taxonomize the migration scenarii from MPLS to GMPLS
networks.
In Section 3, we describe the problems caused by the difference between
MPLS and GMPLS protocols.
In Section 4, we present the required mechanisms, which bridge the
difference between MPLS and GMPLS protocols.
Some of those mechanisms are available today and others are not.
In Section 5, we present the applicability of the required mechanisms to
a reference network model for
the migration from MPLS to GMPLS networks.
.NH 1
Migration scenarii
.XS
\*(SN Migration scenarii
.XE
Two categories of migration scenarii are considered: (1) MPLS-GMPLS-MPLS
and (2)
GMPLS-MPLS-GMPLS. In case of (1) MPLS-GMPLS-MPLS scenario, source and
destination nodes of the Label Switched path (LSP) are in MPLS and a set
of its intermediate nodes take part of GMPLS. In case of (2)
GMPLS-MPLS-GMPLS scenario, LSP
source and destination nodes are in GMPLS network and a set of its
intermediate nodes take part of MPLS network. Each category is
subdivided in two sub-categories as to whether GMPLS is PSC or non-PSC.
MPLS-GMPLS (PSC) migration scenario, where LSP start/end in an MPLS
network and end/start in a GMPLS PSC network, will be addressed in a
future revision.
.NH 2
MPLS-GMPLS(non-PSC)-MPLS
.XS
\*(SN MPLS-GMPLS(non-PSC)-MPLS
.XE
Introduction of a GMPLS-based optical core network to increase the
capacity is an example of this category. TDM, LSC, and/or FSC LSPs are
established between MPLS networks across the GMPLS network.
A set of those LSPs
provide virtual network topology for MPLS networks.
This topology may be
reconfigurable by adding and/or removing those LSPs [MRN]. MPLS LSRs and
subnetworks
interconnected at
the edges of the virtual network topology may form a single MPLS network.
Figure 1 shows the reference network model for the
MPLS-GMPLS(non-PSC)-MPLS migration.
The reference network model consists of three regions: ingress, transit,
and egress.
Both the ingress and egress regions are MPLS-based while the transit
region is GMPLS-based.
The nodes at the boundary of the MPLS and GMPLS regions (G1, G2, G5, and
G6) are referred
to as "border node" hereafter.
All nodes except the border nodes in the GMPLS-based transit region (G3
and G4)
are non-PSC device, i.e., optical equipment (TDM, LSC, and FSC).
An MPLS LSP can be provisioned from
a node in the ingress MPLS-based region (say, R2) to a node in the
egress MPLS-based region (say, R4).
The LSP is referred to as the "e2e" LSP hereafter.
The switching capability of both end points of e2e LSP are the same (PSC).
.KS
................. .............................. ..................
: MPLS : : GMPLS (non-PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<-------------------------------------------------------->|
e2e LSP
Figure 1 MPLS-GMPLS(non-PSC)-MPLS migration model.
.KE
.NH 2
MPLS-GMPLS(PSC)-MPLS
.XS
\*(SN MPLS-GMPLS(PSC)-MPLS
.XE
MPLS-based converged network can be migrated to GMPLS (PSC)-based converged
network.
The rationale of this type of migration scenario is supported by two
factors:
(1) GMPLS-based advanced feature,
(2) stepwise migration for the GMPLS-based optical core network.
Regarding the GMPLS-based
advanced feature, numerous features are being developed in GMPLS context
(and
MPLS) including bi-directional LSP, label control, graceful restart,
graceful teardown
and forwarding adjacencies.
Existing
MPLS-based converged network could be migrated to GMPLS (PSC)-based
converged
network to deliver the advanced features. Once the PSC network is
migrated to
GMPLS-based one, it could be migrated to GMPLS-based optical core
network with
less effort.
.NH 2
GMPLS(non-PSC)-MPLS-GMPLS(non-PSC)
.XS
\*(SN GMPLS(non-PSC)-MPLS-GMPLS(non-PSC)
.XE
In this scenario, TDM, L2SC e2e LSPs are provisioned in the GMPLS
network, which is partly disconnected.
In case the MPLS-based infrastructure network is widely deployed,
it is used to bridge the disconnected GMPLS networks.
Moreover, pseudo wire emulation is used edge-to-edge in the MPLS-based
converged network to
carry those LSPs [PWE3].
Figure 2 shows the reference network model for the
GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration.
The reference network model consists of three regions: ingress, transit,
and egress.
Both the ingress and egress regions are GMPLS-based while the transit
region is MPLS-based.
The nodes at the boundary of the MPLS and GMPLS regions (G3, G4, G5, and
G6) are referred
to as "border node" hereafter.
All nodes except the border nodes in the GMPLS-based regions (G1, G11,
G2, G21, G71, G7, G81, and G8)
are non-PSC devices.
A GMPLS LSP can be provisioned from a node in the ingress GMPLS-based
region (say, G2)
to a node in the egress GMPLS-based region (say, G8).
The LSP is referred to as the "e2e" LSP hereafter.
The switching capability of both end points of e2e LSP must be the same.
.KS
.................. ............................. ..................
: GMPLS(non-PSC) : : MPLS : : GMPLS(non-PSC) :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|G1 |__|G11|___|G3 |__________|R1 |__________|G5 |___|G71|__|G7 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|G2 |__|G21|___|G4 |__________|R2 |__________|G6 |___|G81|__|G8 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<-------------------------------------------------------->|
e2e LSP
Figure 2 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration model.
.KE
.NH 2
GMPLS(PSC)-MPLS-GMPLS(PSC)
.XS
\*(SN GMPLS(PSC)-MPLS-GMPLS(PSC)
.XE
In this scenario, GMPLS PSC e2e LSPs are provisioned in the GMPLS
network, which is partly disconnected.
In case the MPLS-based infrastructure network is widely deployed,
it is used to bridge the disconnected GMPLS networks.
Since MPLS-based network is PSC,
the GMPLS PSC LSP can cross MPLS-based converged network without extra
treatment in
data plane.
.NH 1
Difference between MPLS and GMPLS protocols
.XS
\*(SN Difference between MPLS and GMPLS protocols
.XE
.NH 2
Routing
.XS
\*(SN Routing
.XE
In this document we assume that the OSPF-TE is used as IGP-TE. However
the IGP-TE description should apply to both IS-IS and OSPF. Specifics
concerning IS-IS will be detailed in the next release of this document.
TE-link information is advertised in link state advertisement.
It allows collecting the whole topology information, which is stored in
traffic-engineering data base (TEDB).
Best-effort route and/or traffic-engineered explicit route for the
destination are
calculated using the TEDB.
GMPLS extends the set of sub-TLVs for TE-link advertisements. Non-PSC
TE-link information used in
GMPLS is not supported by MPLS. Even PSC TE-link information used in
GMPLS is not fully
supported by MPLS (this is particularly the case for the Interface
Switching Capability Descriptor sub-TLV).
As a result, one cannot compute
traffic-engineered explicit route if they are travelling through both
MPLS and GMPLS
regions.
Figure 3 illustrates the problem of mismatch of TE-link information in
MPLS and GMPLS.
Suppose that an e2e LSP is provisioned between R2 and R4 and that we
need to compute the path
between R2 and R4 (say, R2-R21-G2-G4-G6-R41-R4).
The TE link information for the links R2-R21, R21-G2, G6-R41 and R41-R4
is MPLS-based TE link LSA, while the ones for the links G2-G4 and G4-G6
is GMPLS-based.
The node in MPLS-based ingress region (say, R2) cannot compute the path,
which consists of mixture of MPLS-based and GMPLS-based TE link information.
.KS
................. .............................. ..................
: 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 3 Problem mismatch of TE-link information in MPLS and GMPLS
.KE
Except for Opaque-LSA associated with TE-link, MPLS and GMPLS use the
same set of LSAs,
e.g., router-LSA, network-LSA, summary-LSA and etc. These LSAs in GMPLS
network construct the topology database of the control plane of GMPLS
network.
.NH 2
Signaling
.XS
\*(SN Signaling
.XE
GMPLS RSVP-TE signalling ([RFC 3473]) introduces new objects, and their
associated procedures, that can not be processed/inserted by MPLS LSRs:
.IP -
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.
.IP -
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.
.IP -
The Suggested Label Object, used to reduce LSP setup delays.
.IP -
The Label Set Object, used to restrict label allocation to a set of
label, which (particularly useful for wavelength conversion incapable nodes)
.IP -
The Upstream Label Object, used for bidirectional LSP setup (see also 3.4)
.IP -
The Restart Cap object, used for graceful restart.
.IP -
The Admin Status object, used for LSP administration, and particularly
for graceful LSP teardown.
.NH 2
Control plane/data plane separation
.XS
\*(SN Control plane/data plane separation
.XE
TDM, LSC, FSC networks do not recognize packet delineation. In GMPLS,
the control
channel can be logically (in-band) or physically (out-of-band) separated
from the data channel in those networks. The control channels
between adjacent nodes constitute a control plane network. Control
packets of routing
and signaling protocols are transmitted over the control plane network.
If the GMPLS network consists of only PSC devices,
there can be no control plane/data plane separation.
All control packets share the same network links with data packets. If
the GMPLS
network consists of non-PSC devices,
there is at least a logical C/D separation at
least between PSC device and non-PSC device in GMPLS networks and
between non-PSC and non-PSC devices.
The GMPLS control plane,
which is designed to carry the control packet in GMPLS network, is not
likely to have enough
capacity to carry the user-data traffic from MPLS network.
Therefore, the control plane must ensure is it not carrying data traffic
from the MPLS network (see [GMPLS-ROUTING]).
.NH 2
Bi-directional LSP
.XS
\*(SN Bi-directional LSP
.XE
Since GMPLS supports TDM, LSC, and FSC switching and LSP classes, which
are mainly bi-directional
channels,
it also provides bi-directional LSP setup. In a single signaling
session, bi-directional
LSPs can be created along the same route in GMPLS network. On the other
hand,
there is no equivalent mechanism to support bi-directional LSPs in MPLS
network. The forward
and backward LSPs are created in different signaling sessions. The route
taken by
those LSPs may be different from each other. Their sessions are treated
differently
from each other.
If MPLS and GMPLS networks are inter-connected, the bi-directional LSPs
from
GMPLS network need to be carried in MPLS network, which does not support
bi-directional LSP setup. At least we need a mechanism allowing to route
the forward and backward LSPs on the
same route.
.NH 1
Required mechanism
.XS
\*(SN Required mechanism
.XE
In this section, we present at set of routing and signalling mechanisms,
in order to bridge the difference between MPLS and GMPLS protocols.
This section only proposes mechanisms for MPLS-GMPLS-MPLS migration.
GMPLS-MPLS-GMPLS (using PWE3 stuff) is for further study.
.NH 2
Routing
.XS
\*(SN Routing
.XE
The entire network consisiting of ingress, transit, and egress regions
(See Fig.1 or 2 for instance) may be either single-area or multi-area
from the IGP perspective.
.NH 3
Single-area
.XS
\*(SN Single-area
.XE
If the entire network is a single-area, the partial topology of
GMPLS-based region, which is consisting of PSC-link, should be visible
to MPLS regions.
GMPLS TE-links are advertised as MPLS TE-links using MPLS-based TE link
information to the MPLS networks so that node in the MPLS region can
understand the GMPLS TE-links. This requires some TE-link information
conversion.
If the GMPLS-based region consists of only non-PSC devices except the
border nodes, PSC-links should be set up between the border nodes.
For example, in Fig. 3, a PSC-link can be set up between G2 and G6.
PSC-links are advertised as the forwarding adjacency (FA) in the GMPLS-
based region.
The e2e LSP can be tunnelled through the FA [HIER].
In the MPLS to GMPLS migration scenarii, FA should be advertised as
TE-links in the MPLS regions, using MPLS-based TE-link information.
A set of FAs across the GMPLS region provides the virtual network
topology (VNT), which can be reconfigured by creating and/or destroying
FAs, to MPLS regions. See [MRN] for details.
MPLS TE-links MAY be understood by the nodes in the GMPLS network, which
can transform MPLS-based TE-link information into GMPLS-based TE-link
information.
.NH 4
Virtual FA
.XS
\*(SN Virtual FA
.XE
If the entire network consists of a single IGP area and the GMPLS-based
region consists of only non-PSC devices except the border nodes, FAs
should be set up between the GMPLS border nodes.
To avoid unnecessary bandwidth consumption non-PSC FA LSP should be
created only if there exists traffic demand between the end points.
In order to compute the path across the GMPLS region, the FA-LSP must be
set up for being advertized as per [HIER].
The "virtual" FA-LSP is defined here to cope with the situation.
The virtual FA-LSP is not instantiated but is advertised as a TE-link by
routing protocol to attract traffic.
The virtual FA may be provisioned using the similar method for
provisioning the secondary LSP in the shared mesh restoration
scheme [P&R].
Or the virtual FA may be just signalled between both end points without
having the transit nodes intervene.
A set of virtual FAs forms the virtual topology for the best-effort
and/or the traffic-engineered route across the GMPLS region. The virtual
topology may be designed taking into account the (forecast) traffic
demand and the available resource in the transit region. The virtual
topology may dynamically change according to the variation of the
(forecast) traffic demand and the available resource in the transit
region to
optimize the tradeoff between network performance and the residual
network capacity. How to design the virtual topology and its changes is
out of scope of this document.
The virtual topology is changed by setting up and/or tearing down
virtual FA-LSP.
Signaling messages are used to exchange the link identifiers in a
similar way of the FA as described in [RFC3477] and [LSP-
HIER].
Unlike the case of FA-LSP, the intermediate nodes may not be involved in
signaling message processing when the virtual FA-LSP is not provisioned
(Just link interface identifiers are exchanged by signaling between
ingress and egress nodes).
Both unnumbered and numbered virtual FAs should be defined.
There is no routing adjacency along the (virtual) FA. There is no hello
packets exchanged between the end points of the (virtual) FA.
When an e2e MPLS LSP is setup through a virtual FA, this should trigger
the setup of a real FA-LSP is the GMPLS network.
.NH 3
Multi-area
.XS
\*(SN Multi-area
.XE
A simple migration approach can also consist in separating MPLS and
GMPLS networks into distinct IGP areas, and then rely
on multi-area routing, path computation, and signaling solutions under
specification in CCAMP WG (ABR acting as a Path Computation Element for
instance).
Basicaly there is no backward compatibility issue when MPLS and GMPLS
LSRs resides in disctinct IGP areas, as TE-link information is not
leaked across area (see see [INTER-AREA-REQ] and [INTER-Domain]).
.NH 2
Signaling
.XS
\*(SN Signaling
.XE
We describe the signaling mechanisms, which can be applied to the
migration scenarii from MPLS to GMPLS.
Three basic cases for the MPLS-GMPLS-MPLS environment are described in
Fig. 4: LSP nesting, LSP converting, and LSP stitching.
LSP nesting: One or more packet LSPs is nested into one LSP.
LSP converting: The end-to-end packet LSP signaling messages (RFC 3209)
is translated at the GMPLS borders into GMPLS RSVP-TE (see RFC 3473).
The GMPLS RSVP-TE segment MUST also be PSC.
This case requires a service interworking function 3209/3473 (at the
control plane level).
LSP stitching: A segment PSC LSP is stitched within an end-to-end packet
LSP.
This case does require a network interworking function (at the control
plane level) since MPLS signaling messages are directed between GMPLS
border nodes.
.KS
................. .............................. ..................
: MPLS : : GMPLS (PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
session for e2e LSPs
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
session for FA/LSP tunnel
|<-------------------------->|
e2e LSP _____________________________
<------------ | FA/LSP tunnel | ----------->
<------------ | | ----------->
<------------ | | ----------->
|_____________________________|
(a) LSP nesting
e2e session
|<-------------------------------------------------------->|
____________ ____________________________ ____________
| MPLS seg. || GMPLS segment || MPLS seg. |
|____________||____________________________||____________|
(b) LSP converting
e2e session
|<-------------------------------------------------------->|
transit session
|<-------------------------->|
____________ ____________________________ ____________
| MPLS seg. || GMPLS segment || MPLS seg. |
|____________||____________________________||____________|
(c) LSP stitching
Figure 4 Comparisons of signaling in MPLS-GMPLS-MPLS migration model.
.KE
.NH 3
LSP nesting
.XS
\*(SN LSP nesting
.XE
Figure 4 (a) illustrates the LSP nesting in the MPLS-GMPLS-MPLS
reference network model.
An FA-LSP is created by setting up the FA-LSP.
FA is established between the boundary of the ingress and the
transit regions and that of the transit and the egress regions.
Three e2e LSPs are provisioned between the nodes in the MPLS-based
ingress region (say, R2) and egress region (say, R4).
These e2e LSPs are tunnelled inside the same FA-LSP across the transit
region.
LSP nesting is different from the LSP stitching and the LSP converting
with respect to data
plane. The e2e LSP is nested inside the FA while there is no nesting in
the LSP
stitching and the LSP converting. Multiple e2e LSPs can be nested inside
a single FA-LSP.
Scalability is hereby attained.
There exist at least two sessions: one for the FA-LSP and the others for
e2e LSP(s).
Along the FA-LSP, the state is created and maintained during the
life-time of the FA-LSP.
When the FA-LSP is re-routed (for example due to re-optimization,
failure recovery, etc.), the FA link is not impacted as
long as the alternative FA-LSP exists.
FA-LSP mechanism applies to MPLS-GMPLS (non PSC)-MPLS and MPLS-GMPLS
(PSC)-MPLS migration scenarii.
.NH 3
LSP converting
.XS
\*(SN LSP converting
.XE
LSP can be converted from MPLS to GMPLS and vice versa at the boundary
of MPLS
and GMPLS regions while remaining in the same session.
This is achieved by delivering an interworking function at the control
plane of the GMPLS border nodes.
Figure 4 (b) illustrates the LSP converting in the MPLS-GMPLS-MPLS
reference network model.
The e2e LSP is provisioned between the nodes in the MPLS-based ingress
region (say, R2) and egress region (say, R4).
The e2e LSP consists of three segments: ingress, transit, egress.
The transit segment is GMPLS-based and therefore it is referred to as
GMPLS-segment while others are referred to as MPLS-segments.
The e2e LSP is associated with the single session, which is referred to
as the "e2e" session.
This is relevant only for MPLS-GMPLS (PSC)-MPLS migration scenario.
.NH 4
MPLS->GMPLS
.XS
\*(SN MPLS->GMPLS
.XE
LSP is converted from MPLS to GMPLS at the boundary of MPLS ingress and
GMPLS transit regions. In case of C/D separation in the GMPLS transit
region, the signaling message is separated from the data plane network
at the boundary.
Regarding the control plane, the signaling message associated with the
e2e LSP is carried in the control plane network in the GMPLS transit
region. Appropriate objects newly defined for GMPLS (say, Generalized
label request object) is attached to the signaling message.
.NH 4
GMPLS->MPLS
.XS
\*(SN GMPLS->MPLS
.XE
LSP is converted from GMPLS to MPLS at the boundary of GMPLS transit and
MPLS egress regions. In case of C/D separation in the GMPLS transit
region, the signaling message from the data plane network is multiplexed
to the data plane message at the boundary. LSP is converted with
respect to both the control and the data plane aspects.
Regarding the control plane aspect, the signaling message objects, which
are not supported by MPLS, are lost. The associated functions are not,
therefore, effective in MPLS network accordingly. GMPLS-segment is
either uni-directional or bi-directional. There is no mechanism to set
up the bi-directional MPLS LSPs within the same session along the same
route.
.NH 4
ERO/RRO processing
.XS
\*(SN ERO/RRO processing
.XE
There are three cases depending on the level of detail of the transit
segment specified as part of the EROs issued in the Path message issued
by the ingress of the e2e LSP.
.IP 1)
The ERO issued by the ingress of the e2e LSP includes the tail-end of
the transit segment as a strict subobject.
Then, if the head-end of the transit segment is also included as a
strict node, in this case ERO processing follows rules described in
Section 8.2 of [LSP-HIER] as the sequence of the transit segment is
complete once issued by the ingress of the e2e LSP.
Otherwise, if the head-end node of the transit segment (or any other
subobject preceding the tail-end) is specified as a loose subobject, the
preceding strict node inserts the sequence of subobjects within the ERO
as specified in [RFC 3209] to reach the next loose node.
.IP 2)
The ERO issued by the ingress of the e2e LSP includes both head- (strict
or loose) and tail-end (loose) of the transit segment. In this case, the
ingress GMPLS border node inserts sequence of subobjects within the ERO
as specified in [RFC 3209] to reach the egress border node.
.IP 3)
The ERO issued by the ingress of the e2e LSP does not include the
tail-end of the transit segment.
In this case, the ingress border node should decide the exit point to
reach the next loose node being outside of the transit region.
.LP
RROs in the transit segment may carry the nodes in the transit region.
The nodes in the
transit segment may be removed from the RROs when they depart from the
transit region.
The ingress and egress border nodes should be included in the RROs when
they are carried
in the ingress and the egress regions.
.NH 3
LSP stitching
.XS
\*(SN LSP stitching
.XE
LSP can be stitched at the boundary of MPLS and GMPLS regions
[Inter-domain].
The LSP stretches from the ingress through the transit to the egress
regions.
Figure 4 (c) illustrates the LSP stitching in the MPLS-GMPLS-MPLS
reference network model.
The e2e LSP is provisioned between the nodes in the MPLS-based ingress
region (say, R2) and egress region (say, R4).
The e2e LSP consists of two segments: ingress/egress and transit.
The transit segment is GMPLS-based and therefore it is referred to as
GMPLS-segment while others are referred to as MPLS-segments.
The e2e LSP is associated with the two sessions: one for the entire
stretch (i.e., ingress to egress regions)
and the other for the transit segment.
The signaling mechanisms described in [INTER-DOMAIN-SIG] can be applied.
.NH 3
Discovery of GMPLS signalling capability
.XS
\*(SN Discovery of GMPLS signalling capability
.XE
I may be useful to advertise into the IGP the capability of a node to
support GMPLS signalling. This would allow every node in the network to
automatically discover the GMPLS signalling regions. [TE-INFO] provides
a functional description of routing extensions in order to advertise TE
router information, including Control Plane Capabilities such as GMPLS
signaling.
.NH 1
MPLS-GMPLS-MPLS reference model
.XS
\*(SN MPLS-GMPLS-MPLS reference model
.XE
In this section, the required mechanisms with the MPLS-GMPLS-MPLS
reference network model is discussed.
FA/LSP tunnel, LSP converting, and LSP stiching are applied to the
reference network model.
From Figure 1, we consider that the packet LSP is set up between the
ingress and the egress regions. The LSP is
referred to as "e2e" LSP hereafter. The LSP portion corresponding to the
transit
GMPLS-base region is referred to as "transit segment". The transit
segment is
implemented by either (1) LSP nesting, (2) LSP converting, or (3) LSP
stitching.
.NH 2
LSP nesting
.XS
\*(SN LSP nesting
.XE
.NH 3
Basic description
.XS
\*(SN Basic description
.XE
FAs are created between the GMPLS border nodes.
The FAs are advertised in the MPLS regions, by the routing protocol,
using MPLS TE-link information ([OSPF-TE] or [ISIS-TE]).
The e2e LSP is tunneled through the FA across the GMPLS-based transit
region.
Multiple e2e LSPs may be tunnelled through a single FA. The e2e LSP may
be carried over
multiple hops of FAs across the GMPLS-based transit region unless there
is no direct
FA between the ingress and the egress regions.
.NH 3
Traffic demand change
.XS
\*(SN Traffic demand change
.XE
Traffic demand may change after the FA is created. Some FAs, which do
not carry any
e2e LSP any longer may be released for resource release. They may
be also retained for future usage.
Release or retention of underutilized FAs is a policy decision.
Detail of the policy is out of scope of this document.
FAs may be created based on the policy, which might consider residual
resource in
GMPLS-based transit region and the change of traffic demand. By creating
the new
FAs, the network performance such as maximum residual capacity may be
improved.
As the number of FAs grows, the residual resource in the GMPLS-based
transit region
may decrease. In this case, re-optimization may be invoked in the
GMPLS-based
transit region according the the policy. Detail of the policy is again
out of scope of this
document.
As part of the reoptimization process, FA-LSPs may be rerouted while
keeping interface identifiers of FA links unchanged. However, the
routing in
MPLS level should be unaffected since there is no change of topology
composed of FAs across
the GMPLS-based transit region.
When residual resource in the GMPLS-based transit region decreases, some
FAs may
be released according to the policy. Detail of the policy is again out
of scope of this
document. The FA should be released only after the LSA associated with
the FA is
deleted throughout the network. Once the LSA is deleted, the e2e LSPs
routed over
the FA are expected to get rerouted around the FA.
.NH 3
Nest of FAs
.XS
\*(SN Nest of FAs
.XE
E2e LSP can be tunneled into the PSC or non-PSC FA LSPs established
between GMPLS border nodes. Further nesting can also occur within the
GMPLS network (see [LSP-HIER]).
Full mesh of PSC FA-LSPs may be created between every border nodes using
a set of non-PSC FA-LSPs across the
GMPLS-based transit region [MAMLTE].
The merit of this mechanism is to attain the stability of MPLS-level
routing, i.e., the forwarding table of the LSR is kept intact even if
the topology composed of a set of non-PSC FA-LSPs are modified.
There is
not topology change from the view point of MPLS-level. Traffic
engineering is
performed by reconfiguring the virtual topology consisting of a set of
non-PSC FAs
across the GMPLS-based transit region.
Thanks to statistical multiplexing gain, there is no waste of bandwidth
resource even if a PSC FA-LSP is created.
.NH 3
Virtual FA
.XS
\*(SN Virtual FA
.XE
The virtual FA can be used instead of the FA to allow the path across the
GMPLS-based transit region to be computed while avoiding waste of
bandwidth and adaptation
port occupation by non-PSC FA.
A set of the virtual FAs forms the virtual topology for the best-effort
and/or the
traffic-engineered route across the GMPLS-based transit region. The
virtual topology
may be designed taking into account the (forecast) traffic demand and
available
resource in the GMPLS-based transit region. How to design the virtual
topology is out
of scope of this document.
The virtual topology may dynamically change according to the change of
the (forecast)
traffic demand and the available resource in the transit region.
The virtual topology is changed by setting up and/or tearing down the
virtual FA.
.NH 2
LSP converting/LSP stitching
.XS
\*(SN LSP converting/LSP stitching
.XE
.NH 3
One-to-one relationship
.XS
\*(SN LSP One-to-one relationship
.XE
LSP converting and LSP stitching have common property when they are
applied to the
reference model for MPLS-GMPLS-MPLS. There is a one-to-one relationship
between the e2e LSP and the transit segment. When the e2e LSP is set up
and/or torn down,
the associated transit segment is set up and/or torn down accordingly.
Due to the one-to-one relationship, these mechanisms are relevant only
for MPLS - GMPLS (PSC) -MPLS scenario.
.NH 3
Traffic demand change
.XS
\*(SN LSP Traffic demand change
.XE
When the traffic demand for the e2e LSP changes, the bandwidth allocated
to the transit segment may be modified.
When the bandwidth is modified in the SENDER_TSPEC/FLOWSPEC object, the
LSP-ID field of SENDER_TEMPLATE object for the e2e LSP is modified in
both methods (make-before-break, see [RFC3209]).
This modification may trigger the same LSP ID change for the transit
segment if its bandwidth needs to be readjusted.
.NH
Acknowledgements
.XS
\*(SN Acknowledgements
.XE
The authors are grateful to Adrian Farrel for his numerous valuable
comments.
.NH
Security Considerations
.XS
\*(SN Security Considerations
.XE
There are not security issues in this draft.
.NH 1
References
.XS
\*(SN References
.XE
.NH 2
Normative references
.XS
\*(SN Normative references
.XE
[RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional
Description", RFC 3471, January 2003.
[RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE
Extensions",
RFC 3473, January 2003.
[GMPLS-ARCH] E. Mannie (Editor), "Generalized Multi-Protocol Label
Switching Architecture,"
<draft-ietf-ccamp-gmpls-architecture-07.txt> (Work in progress), May 2003.
[GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS",
<draft-ietf-ccamp-ospf-gmpls-extensions-12.txt> (work in progress),
October 2003.
[GMPLS-ISIS]
"IS-IS extensions in support of generalized multi-protocol label switching,"
<draft-ietf-isis-gmpls-extensions-19.txt> (work in progress), October 2003.
[GMPLS-LMP] J. Land, "Link management protocol (LMP),"
<draft-ietf-ccamp-lmp-10.txt> (work in progress), October 2003.
[PWE3] S. Bryant, P. Pate (Editors), "PWE3 Architecture,"
<draft-ietf-pwe3-arch-07.txt> (work in progress), March 2003.
[OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering (TE)
Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF] J. Moy, "OSPF Version 2", RFC2328, April 1998.
.NH 2
Informative references
.XS
\*(SN Informative references
.XE
[MRN] D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard. J.L. Le
Roux,
"Generalized MPLS Architecture for Multi-Region Networks,"
<draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt> (work in progress),
February 2004.
[GMPLS-ROUTING] K. Kompella and Y. Rekhter, "Routing Extensions in Support
of Generalized Multi-Protocol Label Switching,"
<draft-ietf-ccamp-gmpls-routing-09.txt> (work in progress), October 2003.
[Inter-domain] A. Farrel, J-P. Vasseur, and A. Ayyangar, "A framework
for inter-domain
MPLS traffic engineering,"
<draft-farrel-ccamp-inter-domain-framework-00.txt>
(work in progress), April 2004.
[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS
TE," <draft-ietf-mpls-lsp-hierarchy-08.txt> (work in progress),
September 2002.
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in
Resource
ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC3477, January,
2003.
[MAMLTE] K. Shiomoto et al.,
"Multi-area multi-layer traffic engineering using hierarchical LSPs in
GMPLS networks,"
<draft-shiomoto-multiarea-te-01.txt> (work in progress), June 2002.
[P&R] J.P. Lang, Y. Rekhter, D. Papadimitriou (Editors), "RSVP-TE
Extensions in support of End-to-End GMPLS-based Recovery",
<draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt> (work in
progress), May 2004.
[GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the Overlay
Model,"
<draft-ietf-ccamp-gmpls-overlay-04.txt> (work in progress), April 2004.
[GMPLS-RECOVERY] CCAMP P&R Design Team, "Analysis of Generalized
Multi-Protocol Label
Switching (GMPLS)-based Recovery Mechanisms (including Protection and
Restoration),"
<draft-ietf-ccamp-gmpls-recovery-analysis-03.txt> (work in Progress),
April 2004.
[TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions for
discovery of TE router information",
<draft-vasseur-ccamp-te-router-info-00.txt> (work in progress), July 2004.
[INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS
traffic engineering RSVP extensions",
<draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt> (work in progress),
July 2004.
[MPLS-FRR] Ping Pan et. at., "Fast reroute extensions to RSVP-TE for
LSP tunnels," <draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. (work in
progress), May 2004.
[GMPLS-SR] Louis Berger, Igor Bryskin, Dimitri Papadimitriou, Adrian Farrel,
"GMPLS Based Segment
Recovery,"<draft-ietf-ccamp-gmpls-segment-recovery-00.txt> (work in
progress), March 2004.
[INTER-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements for
Inter-Area MPLS Traffic Engineering",
<draft-ietf-tewg-interarea-mpls-te-req-02.txt>,
June 2004.
.NH
Author's Address
.XS
\*(SN Author's Address
.XE
.nf
Deborah Brungard
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 420 1573
E-mail: dbrungard@att.com
Jean-Louis Le Roux
France Telecom R&D
av Pierre Marzin
22300 Lannion
France
E-mail: jeanlouis.leroux@francetelecom.com
.nf
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
E-mail: oki.eiji@lab.ntt.co.jp
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
E-mail: dimitri.papadimitriou@alcatel.be
Daisaku Shimazaki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
E-mail: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
E-mail: shiomoto.kohei@lab.ntt.co.jp
.NH
Intellectual Property Rights Notices
.XS
\*(SN Intellectual Property Rights Notices
.XE
The IETF takes no position regarding the validity or scope of any
intellectual property
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; neither does it represent that
it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect
to rights in standards-track and standards-related documentation can be
found in
BCP-11. Copies of claims of rights made available for publication 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 implementors
or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents
or patent applications, or other proprietary rights which may cover
technology that
may be required to practice this standard. Please address the
information to the
IETF Executive Director.
.NH 2
IPR Disclosure Acknowledgement
.XS
\*(SN IPR Disclosure Acknowledgement
.XE
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.
.SH
Full Copyright Statement
.XS
Full Copyright Statement
.XE
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and
derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in
whole or in
part, without restriction of any kind, provided that the above copyright
notice and this
paragraph are included on all such copies and derivative works.
However, this
document itself may not be modified in any way, such as by removing the
copyright
notice or references to the Internet Society or other Internet
organizations, except as
needed for the purpose of developing Internet standards in which case
the procedures
for copyrights defined in the Internet Standards process must be
followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the
Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS
IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.
.TC
================================ NORFF file end
=============================
Dinara Suleymanova wrote:
> Resubmit this draft to my e-mail address ASAP in a just plain TXT file
> attachment.
>
>
> At 07:36 PM 7/18/2004, you wrote:
>
>> Dear IETF Secretariat,
>> CC: Kireeti and Adrian,
>>
>> I would like to submit a 03-version draft in the following.
>> Attached please find draft files (txt and nroff).
>> This draft is targeted as CCAMP WG.
>> Thank you.
>> ---
>> Kohei Shiomoto
>> ---------------------------------------------------------------------------
>>
>> Title: Migrating from IP/MPLS to GMPLS networks
>> <draft-oki-ccamp-gmpls-ip-interworking-03.txt>
>> Authors: Deborah Brungard, Jean-Louis Le Roux, Eiji Oki,
>> Dimitri Papadimitriou, Daisaku Shimazaki, Kohei Shiomoto
>> Abstract:
>> This document is addressing the migration from Multi-protocol label
>> switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to
>> expand the capacity of the existing MPLS-based infrastructure network,
>> the optical network consisting of L2SC, TDM, LSC, and FSC devices will
>> be deployed, which is controlled by the GMPLS protocols. GMPLS protocols
>> are, however, subtly different from MPLS protocols. In this document we
>> describe possible migration scenarii, the mechanisms to compensate the
>> difference between MPLS and GMPLS protocols, and how the mechanisms are
>> applied to migrate from the MPLS to the GMPLS network.
>>
>> --
>> Kohei Shiomoto, Ph.D
>> NTT Network Service Systems Laboratories
>> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
>> Phone +81 422 59 4402 Fax +81 422 59 4549
>>
>> CCAMP Working Group Deborah Brungard (AT&T)
>> Internet Draft Jean-Louis Le Roux (France Telecom)
>> Expiration Date: December 2004 Eiji Oki
>> (NTT) Dimitri Papadimitriou
>> (Alcatel) Daisaku
>> Shimazaki (NTT)
>> Kohei Shiomoto
>> (NTT) July
>> 2004 Migrating from IP/MPLS to GMPLS
>> networks draft-oki-ccamp-gmpls-ip-interworking-03.txt
>> Status of this Memo This document is an Internet-Draft and is in
>> full conformance with all provisions of Section 10 of RFC2026.
>> 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. By submitting this
>> Internet-Draft, I certify that any applicable patent or other IPR
>> claims of which I am aware have been disclosed, and any of which I
>> become aware will be disclosed, in accordance with RFC 3668.
>> Copyright Notice Copyright (C) The Internet Society (2004). All
>> Rights Reserved. [Page 1] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 Abstract
>> This document is addressing the migration from Multi-protocol label
>> switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to
>> expand the capacity of the existing MPLS-based infrastructure
>> network, the optical network consisting of L2SC, TDM, LSC, and FSC
>> devices will be deployed, which is controlled by the GMPLS protocols.
>> GMPLS protocols are, however, subtly different from MPLS protocols.
>> In this document we describe possible migration scenarii, the
>> mechanisms to compensate the difference between MPLS and GMPLS
>> protocols, and how the mechanisms are applied to migrate from the
>> MPLS to the GMPLS network. 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. 1. Introduction
>> Multi-protocol label switching (MPLS) is widely deployed with
>> applica- tions such as traffic engineering and virtual private
>> network (VPN). Various kinds of services such as VoIP, IPv6,
>> L2VPN/L3VPN, pseudo wire emulation are expected to be converged over
>> the MPLS-based infrastruc- ture network. Traffic volume is
>> tremendously increasing as broadband service enabled by ADSL and FTTH
>> is rapidly penetrating the market and the processing performance of
>> terminal and server is ever increasing. In order to cope with such
>> increase of the traffic volume, optical networks, which con- sists of
>> L2SC, TDM, LSC, and FSC devices, will be introduced. Generalized MPLS
>> (GMPLS) is being standardized by extending MPLS to con- trol such
>> optical networks (see [RFC3471], [RFC3473], [GMPLS-ROUTING],
>> [GMPLS-OSPF], [GMPLS-ISIS], [GMPLS-LMP]). GMPLS network will be
>> deployed as a part of the existing MPLS infractructure. MPLS and
>> GMPLS devices will coexist in the network until the existing MPLS
>> network is com- pletely migrated to the GMPLS network. GMPLS
>> protocols are, however, subtly extending MPLS protocols' capabili-
>> ties. In order to migrate from the existing MPLS to the GMPLS
>> network, we need to define mechanisms to compensate the difference
>> between MPLS [Page 2] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 and GMPLS.
>> In this document we discuss the migration scenarii from MPLS to GMPLS
>> networks, the mechanisms to compensate the difference between MPLS
>> and GMPLS, and the applicability of the mechanisms to the possible
>> migration scenarii. We should note that GMPLS covers Packet Switching
>> Capable (PSC) networks [GMPLS-ARCH]. In the rest of this document,
>> when dealing with GMPLS, it means both PSC and non-PSC. Otherwise
>> PSC GMPLS or non-PSC GMPLS is explicitly mentioned. GMPLS introduces
>> new features such as bidirectional LSPs, label sugges- tion, label
>> restriction, graceful restart, graceful teardown, and for- warding
>> adjacencies (see [GMPLS-ARCH]). Also several features are pro- vided
>> in a distinct manner. For instance local protection is provided using
>> distinct mechanisms in MPLS (see [MPLS-FRR]) and GMPLS (see
>> [GMPLS-SR]). Migration from MPLS to GMPLS should bring these
>> features and such distinct mechanisms in the existing MPLS-based
>> infrastructure network. The rest of this document is organized as
>> follows. In Section 2, we taxonomize the migration scenarii from
>> MPLS to GMPLS networks. In Sec- tion 3, we describe the problems
>> caused by the difference between MPLS and GMPLS protocols. In
>> Section 4, we present the required mechanisms, which bridge the
>> difference between MPLS and GMPLS protocols. Some of those
>> mechanisms are available today and others are not. In Section 5, we
>> present the applicability of the required mechanisms to a reference
>> network model for the migration from MPLS to GMPLS networks. 2.
>> Migration scenarii Two categories of migration scenarii are
>> considered: (1) MPLS-GMPLS-MPLS and (2) GMPLS-MPLS-GMPLS. In case of
>> (1) MPLS-GMPLS-MPLS scenario, source and destination nodes of the
>> Label Switched path (LSP) are in MPLS and a set of its intermediate
>> nodes take part of GMPLS. In case of (2) GMPLS-MPLS-GMPLS scenario,
>> LSP source and destination nodes are in GMPLS network and a set of
>> its intermediate nodes take part of MPLS net- work. Each category is
>> subdivided in two sub-categories as to whether GMPLS is PSC or
>> non-PSC. MPLS-GMPLS (PSC) migration scenario, where LSP start/end in
>> an MPLS net- work and end/start in a GMPLS PSC network, will be
>> addressed in a future revision. [Page 3] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 2.1.
>> MPLS-GMPLS(non-PSC)-MPLS Introduction of a GMPLS-based optical core
>> network to increase the capacity is an example of this category. TDM,
>> LSC, and/or FSC LSPs are established between MPLS networks across the
>> GMPLS network. A set of those LSPs provide virtual network topology
>> for MPLS networks. This topology may be reconfigurable by adding
>> and/or removing those LSPs [MRN]. MPLS LSRs and subnetworks
>> interconnected at the edges of the vir- tual network topology may
>> form a single MPLS network. Figure 1 shows the reference network
>> model for the MPLS-GMPLS(non- PSC)-MPLS migration. The reference
>> network model consists of three regions: ingress, transit, and
>> egress. Both the ingress and egress regions are MPLS-based while the
>> transit region is GMPLS-based. The nodes at the boundary of the MPLS
>> and GMPLS regions (G1, G2, G5, and G6) are referred to as "border
>> node" hereafter. All nodes except the border nodes in the
>> GMPLS-based transit region (G3 and G4) are non-PSC device, i.e.,
>> optical equipment (TDM, LSC, and FSC). An MPLS LSP can be provi-
>> sioned from a node in the ingress MPLS-based region (say, R2) to a
>> node in the egress MPLS-based region (say, R4). The LSP is referred
>> to as the "e2e" LSP hereafter. The switching capability of both end
>> points of 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 1 MPLS-GMPLS(non-PSC)-MPLS migration model.
>> [Page 4] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 2.2.
>> MPLS-GMPLS(PSC)-MPLS MPLS-based converged network can be migrated to
>> GMPLS (PSC)-based con- verged network. The rationale of this type of
>> migration scenario is supported by two factors: (1) GMPLS-based
>> advanced feature, (2) stepwise migration for the GMPLS-based optical
>> core network. Regarding the GMPLS-based advanced feature, numerous
>> features are being developed in GMPLS context (and MPLS) including
>> bi-directional LSP, label control, graceful restart, graceful
>> teardown and forwarding adjacencies. Exist- ing MPLS-based converged
>> network could be migrated to GMPLS (PSC)-based converged network to
>> deliver the advanced features. Once the PSC network is migrated to
>> GMPLS-based one, it could be migrated to GMPLS-based optical core
>> network with less effort. 2.3. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) In
>> this scenario, TDM, L2SC e2e LSPs are provisioned in the GMPLS net-
>> work, which is partly disconnected. In case the MPLS-based
>> infrastruc- ture network is widely deployed, it is used to bridge the
>> disconnected GMPLS networks. Moreover, pseudo wire emulation is used
>> edge-to-edge in the MPLS-based converged network to carry those LSPs
>> [PWE3]. Figure 2 shows the reference network model for the
>> GMPLS(non-PSC)-MPLS- GMPLS(non-PSC) migration. The reference network
>> model consists of three regions: ingress, transit, and egress. Both
>> the ingress and egress regions are GMPLS-based while the transit
>> region is MPLS-based. The nodes at the boundary of the MPLS and
>> GMPLS regions (G3, G4, G5, and G6) are referred to as "border node"
>> hereafter. All nodes except the border nodes in the GMPLS-based
>> regions (G1, G11, G2, G21, G71, G7, G81, and G8) are non-PSC
>> devices. A GMPLS LSP can be provisioned from a node in the ingress
>> GMPLS-based region (say, G2) to a node in the egress GMPLS- based
>> region (say, G8). The LSP is referred to as the "e2e" LSP here-
>> after. The switching capability of both end points of e2e LSP must
>> be the same. [Page 5] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
>> .................. ............................. ..................
>> : GMPLS(non-PSC) : : MPLS : : GMPLS(non-PSC) :
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :|G1 |__|G11|___|G3 |__________|R1 |__________|G5 |___|G71|__|G7 |:
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> : ________/ : : ________/ | ________/ : : ________/ :
>> :| / : : / | / : : / :
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> :|G2 |__|G21|___|G4 |__________|R2 |__________|G6 |___|G81|__|G8 |:
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :................: :...........................: :................:
>> |<-------------------------------------------------------->| e2e
>> LSP Figure 2 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration
>> model. 2.4. GMPLS(PSC)-MPLS-GMPLS(PSC) In this scenario, GMPLS PSC
>> e2e LSPs are provisioned in the GMPLS net- work, which is partly
>> disconnected. In case the MPLS-based infrastruc- ture network is
>> widely deployed, it is used to bridge the disconnected GMPLS
>> networks. Since MPLS-based network is PSC, the GMPLS PSC LSP can
>> cross MPLS-based converged network without extra treatment in data
>> plane. 3. Difference between MPLS and GMPLS protocols 3.1. Routing
>> In this document we assume that the OSPF-TE is used as IGP-TE.
>> However the IGP-TE description should apply to both IS-IS and OSPF.
>> Specifics concerning IS-IS will be detailed in the next release of
>> this document. TE-link information is advertised in link state
>> advertisement. It allows collecting the whole topology information,
>> which is stored in traffic-engineering data base (TEDB). Best-effort
>> route and/or traffic- engineered explicit route for the destination
>> are calculated using the TEDB. [Page 6] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 GMPLS
>> extends the set of sub-TLVs for TE-link advertisements. Non-PSC
>> TE-link information used in GMPLS is not supported by MPLS. Even PSC
>> TE- link information used in GMPLS is not fully supported by MPLS
>> (this is particularly the case for the Interface Switching Capability
>> Descriptor sub-TLV). As a result, one cannot compute
>> traffic-engineered explicit route if they are travelling through both
>> MPLS and GMPLS regions. Figure 3 illustrates the problem of mismatch
>> of TE-link information in MPLS and GMPLS. Suppose that an e2e LSP is
>> provisioned between R2 and R4 and that we need to compute the path
>> between R2 and R4 (say, R2-R21-G2-G4-G6-R41-R4). The TE link
>> information for the links R2-R21, R21-G2, G6-R41 and R41-R4 is
>> MPLS-based TE link LSA, while the ones for the links G2-G4 and G4-G6
>> is GMPLS-based. The node in MPLS-based ingress region (say, R2)
>> cannot compute the path, which consists of mix- ture of MPLS-based
>> and GMPLS-based TE link 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 3
>> Problem mismatch of TE-link information in MPLS and GMPLS Except for
>> Opaque-LSA associated with TE-link, MPLS and GMPLS use the same set
>> of LSAs, e.g., router-LSA, network-LSA, summary-LSA and etc. These
>> LSAs in GMPLS network construct the topology database of the con-
>> trol plane of GMPLS network. 3.2. Signaling GMPLS RSVP-TE signalling
>> ([RFC 3473]) introduces new objects, and their associated procedures,
>> that can not be processed/inserted by MPLS LSRs: [Page 7] E. Oki et
>> al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 -
>> The (Generalized) Label Request object (new C-Type), used to
>> iden- tify the LSP encoding type, the switching type and the
>> generalized protocol ID (G-PID) associated with the LSP. -
>> The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID
>> ERO/RRO subobjects that handle the Control plane/Data plane
>> separa- tion in GMPLS network. - The Suggested Label Object,
>> used to reduce LSP setup delays. - The Label Set Object, used to
>> restrict label allocation to a set of label, which (particularly
>> useful for wavelength conversion inca- pable nodes) - The
>> Upstream Label Object, used for bidirectional LSP setup (see
>> also 3.4) - The Restart Cap object, used for graceful restart.
>> - The Admin Status object, used for LSP administration, and
>> particu- larly for graceful LSP teardown. 3.3. Control
>> plane/data plane separation TDM, LSC, FSC networks do not recognize
>> packet delineation. In GMPLS, the control channel can be logically
>> (in-band) or physically (out-of- band) separated from the data
>> channel in those networks. The control channels between adjacent
>> nodes constitute a control plane network. Con- trol packets of
>> routing and signaling protocols are transmitted over the control
>> plane network. If the GMPLS network consists of only PSC devices,
>> there can be no con- trol plane/data plane separation. All control
>> packets share the same network links with data packets. If the GMPLS
>> network consists of non- PSC devices, there is at least a logical C/D
>> separation at least between PSC device and non-PSC device in GMPLS
>> networks and between non-PSC and non-PSC devices. The GMPLS control
>> plane, which is designed to carry the control packet in GMPLS
>> network, is not likely to have enough capacity to carry the user-data
>> traffic from MPLS network. Therefore, the control plane must ensure
>> is it not carrying data traffic from the MPLS network (see
>> [GMPLS-ROUTING]). [Page 8] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 3.4.
>> Bi-directional LSP Since GMPLS supports TDM, LSC, and FSC switching
>> and LSP classes, which are mainly bi-directional channels, it also
>> provides bi-directional LSP setup. In a single signaling session,
>> bi-directional LSPs can be created along the same route in GMPLS
>> network. On the other hand, there is no equivalent mechanism to
>> support bi-directional LSPs in MPLS network. The forward and backward
>> LSPs are created in different signaling sessions. The route taken by
>> those LSPs may be different from each other. Their sessions are
>> treated differently from each other. If MPLS and GMPLS networks are
>> inter-connected, the bi-directional LSPs from GMPLS network need to
>> be carried in MPLS network, which does not support bi-directional LSP
>> setup. At least we need a mechanism allowing to route the forward and
>> backward LSPs on the same route. 4. Required mechanism In this
>> section, we present at set of routing and signalling mechanisms, in
>> order to bridge the difference between MPLS and GMPLS protocols. This
>> section only proposes mechanisms for MPLS-GMPLS-MPLS migration.
>> GMPLS-MPLS-GMPLS (using PWE3 stuff) is for further study. 4.1.
>> Routing The entire network consisiting of ingress, transit, and
>> egress regions (See Fig.1 or 2 for instance) may be either
>> single-area or multi-area from the IGP perspective. 4.1.1.
>> Single-area If the entire network is a single-area, the partial
>> topology of GMPLS- based region, which is consisting of PSC-link,
>> should be visible to MPLS regions. GMPLS TE-links are advertised as
>> MPLS TE-links using MPLS- based TE link information to the MPLS
>> networks so that node in the MPLS region can understand the GMPLS
>> TE-links. This requires some TE-link [Page 9] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
>> information conversion. If the GMPLS-based region consists of only
>> non-PSC devices except the border nodes, PSC-links should be set up
>> between the border nodes. For example, in Fig. 3, a PSC-link can be
>> set up between G2 and G6. PSC- links are advertised as the
>> forwarding adjacency (FA) in the GMPLS- based region. The e2e LSP
>> can be tunnelled through the FA [HIER]. In the MPLS to GMPLS
>> migration scenarii, FA should be advertised as TE- links in the MPLS
>> regions, using MPLS-based TE-link information. A set of FAs across
>> the GMPLS region provides the virtual network topol- ogy (VNT), which
>> can be reconfigured by creating and/or destroying FAs, to MPLS
>> regions. See [MRN] for details. MPLS TE-links MAY be understood by
>> the nodes in the GMPLS network, which can transform MPLS-based
>> TE-link information into GMPLS-based TE-link information. 4.1.1.1.
>> Virtual FA If the entire network consists of a single IGP area and
>> the GMPLS-based region consists of only non-PSC devices except the
>> border nodes, FAs should be set up between the GMPLS border nodes.
>> To avoid unnecessary bandwidth consumption non-PSC FA LSP should be
>> created only if there exists traffic demand between the end points.
>> In order to compute the path across the GMPLS region, the FA-LSP must
>> be set up for being advertized as per [HIER]. The "virtual" FA-LSP
>> is defined here to cope with the situation. The virtual FA-LSP is
>> not instantiated but is advertised as a TE-link by routing protocol
>> to attract traffic. The virtual FA may be provisioned using the
>> similar method for provisioning the secondary LSP in the shared mesh
>> restoration scheme [P&R]. Or the virtual FA may be just signalled
>> between both end points without having the transit nodes intervene. A
>> set of virtual FAs forms the virtual topology for the best-effort
>> and/or the traffic-engineered route across the GMPLS region. The
>> virtual topology may be designed taking into account the (forecast)
>> traffic demand and the available resource in the transit region. The
>> virtual topology may dynamically change according to the variation of
>> the (fore- cast) traffic demand and the available resource in the
>> transit region to optimize the tradeoff between network performance
>> and the residual net- work capacity. How to design the virtual
>> topology and its changes is out of scope of this document. The
>> virtual topology is changed by setting up and/or tearing down [Page
>> 10] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt
>> July 2004 virtual FA-LSP. Signaling messages are used to exchange
>> the link iden- tifiers in a similar way of the FA as described in
>> [RFC3477] and [LSP- HIER]. Unlike the case of FA-LSP, the
>> intermediate nodes may not be involved in signaling message
>> processing when the virtual FA-LSP is not provisioned (Just link
>> interface identifiers are exchanged by signaling between ingress and
>> egress nodes). Both unnumbered and numbered virtual FAs should be
>> defined. There is no routing adjacency along the (virtual) FA. There
>> is no hello packets exchanged between the end points of the (virtual)
>> FA. When an e2e MPLS LSP is setup through a virtual FA, this should
>> trigger the setup of a real FA-LSP is the GMPLS network. 4.1.2.
>> Multi-area A simple migration approach can also consist in separating
>> MPLS and GMPLS networks into distinct IGP areas, and then rely on
>> multi-area routing, path computation, and signaling solutions under
>> specification in CCAMP WG (ABR acting as a Path Computation Element
>> for instance). Basicaly there is no backward compatibility issue when
>> MPLS and GMPLS LSRs resides in disctinct IGP areas, as TE-link
>> information is not leaked across area (see see [INTER-AREA-REQ] and
>> [INTER-Domain]). 4.2. Signaling We describe the signaling
>> mechanisms, which can be applied to the migra- tion scenarii from
>> MPLS to GMPLS. Three basic cases for the MPLS-GMPLS- MPLS
>> environment are described in Fig. 4: LSP nesting, LSP converting, and
>> LSP stitching. LSP nesting: One or more packet LSPs is nested into
>> one LSP. LSP converting: The end-to-end packet LSP signaling messages
>> (RFC 3209) is translated at the GMPLS borders into GMPLS RSVP-TE (see
>> RFC 3473). The GMPLS RSVP-TE segment MUST also be PSC. This case
>> requires a ser- vice interworking function 3209/3473 (at the control
>> plane level). LSP stitching: A segment PSC LSP is stitched within an
>> end-to-end packet LSP. This case does require a network interworking
>> function (at the control plane level) since MPLS signaling messages
>> are directed between GMPLS border nodes. [Page 11] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
>> ................. .............................. ..................
>> : MPLS : : GMPLS (PSC) : : MPLS :
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> : ________/ : : ________/ | ________/ : : ________/ :
>> :| / : : / | / : : / :
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :................: :...........................:
>> :................: session for e2e
>> LSPs
>> |<-------------------------------------------------------->|
>> |<-------------------------------------------------------->|
>> |<-------------------------------------------------------->| session
>> for FA/LSP tunnel
>> |<-------------------------->| e2e LSP
>> _____________________________ <------------ | FA/LSP
>> tunnel | -----------> <------------
>> | | -----------> <------------
>> | | ----------->
>> |_____________________________| (a) LSP
>> nesting e2e session
>> |<-------------------------------------------------------->|
>> ____________ ____________________________ ____________ |
>> MPLS seg. || GMPLS segment || MPLS seg. |
>> |____________||____________________________||____________|
>> (b) LSP
>> converting e2e session
>> |<-------------------------------------------------------->|
>> transit session
>> |<-------------------------->| ____________
>> ____________________________ ____________ | MPLS seg.
>> || GMPLS segment || MPLS seg. |
>> |____________||____________________________||____________|
>> (c) LSP stitching Figure 4 Comparisons of
>> signaling in MPLS-GMPLS-MPLS migration model. [Page 12] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 4.2.1.
>> LSP nesting Figure 4 (a) illustrates the LSP nesting in the
>> MPLS-GMPLS-MPLS refer- ence network model. An FA-LSP is created by
>> setting up the FA-LSP. FA is established between the boundary of the
>> ingress and the transit regions and that of the transit and the
>> egress regions. Three e2e LSPs are provisioned between the nodes in
>> the MPLS-based ingress region (say, R2) and egress region (say, R4).
>> These e2e LSPs are tunnelled inside the same FA-LSP across the
>> transit region. LSP nesting is different from the LSP stitching and
>> the LSP converting with respect to data plane. The e2e LSP is nested
>> inside the FA while there is no nesting in the LSP stitching and the
>> LSP converting. Multi- ple e2e LSPs can be nested inside a single
>> FA-LSP. Scalability is hereby attained. There exist at least two
>> sessions: one for the FA-LSP and the others for e2e LSP(s). Along
>> the FA-LSP, the state is created and maintained dur- ing the
>> life-time of the FA-LSP. When the FA-LSP is re-routed (for example
>> due to re-optimization, failure recovery, etc.), the FA link is not
>> impacted as long as the alternative FA-LSP exists. FA-LSP mechanism
>> applies to MPLS-GMPLS (non PSC)-MPLS and MPLS-GMPLS (PSC)-MPLS
>> migration scenarii. 4.2.2. LSP converting LSP can be converted from
>> MPLS to GMPLS and vice versa at the boundary of MPLS and GMPLS
>> regions while remaining in the same session. This is achieved by
>> delivering an interworking function at the control plane of the GMPLS
>> border nodes. Figure 4 (b) illustrates the LSP converting in the
>> MPLS-GMPLS-MPLS reference network model. The e2e LSP is provisioned
>> between the nodes in the MPLS-based ingress region (say, R2) and
>> egress region (say, R4). The e2e LSP consists of three segments:
>> ingress, transit, egress. The transit segment is GMPLS-based and
>> therefore it is referred to as GMPLS-segment while others are
>> referred to as MPLS-seg- ments. The e2e LSP is associated with the
>> single session, which is referred to as the "e2e" session. This is
>> relevant only for MPLS-GMPLS (PSC)-MPLS migration scenario. 4.2.2.1.
>> MPLS->GMPLS LSP is converted from MPLS to GMPLS at the boundary of
>> MPLS ingress and GMPLS transit regions. In case of C/D separation in
>> the GMPLS transit [Page 13] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 region,
>> the signaling message is separated from the data plane network at the
>> boundary. Regarding the control plane, the signaling message
>> associated with the e2e LSP is carried in the control plane network
>> in the GMPLS transit region. Appropriate objects newly defined for
>> GMPLS (say, Generalized label request object) is attached to the
>> signaling message. 4.2.2.2. GMPLS->MPLS LSP is converted from GMPLS
>> to MPLS at the boundary of GMPLS transit and MPLS egress regions. In
>> case of C/D separation in the GMPLS transit region, the signaling
>> message from the data plane network is multiplexed to the data plane
>> message at the boundary. LSP is converted with respect to both the
>> control and the data plane aspects. Regarding the control plane
>> aspect, the signaling message objects, which are not supported by
>> MPLS, are lost. The associated functions are not, therefore,
>> effective in MPLS network accordingly. GMPLS-segment is either
>> uni-directional or bi-directional. There is no mechanism to set up
>> the bi-directional MPLS LSPs within the same session along the same
>> route. 4.2.2.3. ERO/RRO processing There are three cases depending
>> on the level of detail of the transit segment specified as part of
>> the EROs issued in the Path message issued by the ingress of the e2e
>> LSP. 1) The ERO issued by the ingress of the e2e LSP includes the
>> tail-end of the transit segment as a strict subobject. Then, if
>> the head- end of the transit segment is also included as a
>> strict node, in this case ERO processing follows rules described
>> in Section 8.2 of [LSP-HIER] as the sequence of the transit
>> segment is complete once issued by the ingress of the e2e LSP.
>> Otherwise, if the head-end node of the transit segment (or any
>> other subobject preceding the tail-end) is specified as a loose
>> subobject, the preceding strict node inserts the sequence of
>> subobjects within the ERO as specified in [RFC 3209] to reach
>> the next loose node. [Page 14] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 2) The
>> ERO issued by the ingress of the e2e LSP includes both head-
>> (strict or loose) and tail-end (loose) of the transit segment.
>> In this case, the ingress GMPLS border node inserts sequence of
>> subob- jects within the ERO as specified in [RFC 3209] to reach
>> the egress border node. 3) The ERO issued by the ingress of
>> the e2e LSP does not include the tail-end of the transit
>> segment. In this case, the ingress border node should decide
>> the exit point to reach the next loose node being outside of the
>> transit region. RROs in the transit segment may carry the nodes in
>> the transit region. The nodes in the transit segment may be removed
>> from the RROs when they depart from the transit region. The ingress
>> and egress border nodes should be included in the RROs when they are
>> carried in the ingress and the egress regions. 4.2.3. LSP stitching
>> LSP can be stitched at the boundary of MPLS and GMPLS regions [Inter-
>> domain]. The LSP stretches from the ingress through the transit to
>> the egress regions. Figure 4 (c) illustrates the LSP stitching in
>> the MPLS- GMPLS-MPLS reference network model. The e2e LSP is
>> provisioned between the nodes in the MPLS-based ingress region (say,
>> R2) and egress region (say, R4). The e2e LSP consists of two
>> segments: ingress/egress and transit. The transit segment is
>> GMPLS-based and therefore it is referred to as GMPLS-segment while
>> others are referred to as MPLS-seg- ments. The e2e LSP is associated
>> with the two sessions: one for the entire stretch (i.e., ingress to
>> egress regions) and the other for the transit segment. The signaling
>> mechanisms described in [INTER-DOMAIN- SIG] can be applied. 4.2.4.
>> Discovery of GMPLS signalling capability I may be useful to advertise
>> into the IGP the capability of a node to support GMPLS signalling.
>> This would allow every node in the network to automatically discover
>> the GMPLS signalling regions. [TE-INFO] provides a functional
>> description of routing extensions in order to advertise TE router
>> information, including Control Plane Capabilities such as GMPLS
>> signaling. [Page 15] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 5.
>> MPLS-GMPLS-MPLS reference model In this section, the required
>> mechanisms with the MPLS-GMPLS-MPLS refer- ence network model is
>> discussed. FA/LSP tunnel, LSP converting, and LSP stiching are
>> applied to the reference network model. From Figure 1, we consider
>> that the packet LSP is set up between the ingress and the egress
>> regions. The LSP is referred to as "e2e" LSP hereafter. The LSP
>> portion corresponding to the transit GMPLS-base region is referred to
>> as "transit segment". The transit segment is implemented by either
>> (1) LSP nesting, (2) LSP converting, or (3) LSP stitching. 5.1. LSP
>> nesting 5.1.1. Basic description FAs are created between the GMPLS
>> border nodes. The FAs are advertised in the MPLS regions, by the
>> routing protocol, using MPLS TE-link infor- mation ([OSPF-TE] or
>> [ISIS-TE]). The e2e LSP is tunneled through the FA across the
>> GMPLS-based transit region. Multiple e2e LSPs may be tunnelled
>> through a single FA. The e2e LSP may be carried over multiple hops of
>> FAs across the GMPLS-based transit region unless there is no direct
>> FA between the ingress and the egress regions. 5.1.2. Traffic demand
>> change Traffic demand may change after the FA is created. Some FAs,
>> which do not carry any e2e LSP any longer may be released for
>> resource release. They may be also retained for future usage.
>> Release or retention of underutilized FAs is a policy decision.
>> Detail of the policy is out of scope of this document. FAs may be
>> created based on the policy, which might consider residual resource
>> in GMPLS-based transit region and the change of traffic demand. By
>> creating the new FAs, the network performance such as maximum resid-
>> ual capacity may be improved. As the number of FAs grows, the
>> residual resource in the GMPLS-based transit region may decrease. In
>> this case, re-optimization may be invoked in the GMPLS-based transit
>> region according the the policy. [Page 16] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 Detail of
>> the policy is again out of scope of this document. As part of the
>> reoptimization process, FA-LSPs may be rerouted while keeping
>> interface identifiers of FA links unchanged. However, the rout- ing
>> in MPLS level should be unaffected since there is no change of
>> topology composed of FAs across the GMPLS-based transit region. When
>> residual resource in the GMPLS-based transit region decreases, some
>> FAs may be released according to the policy. Detail of the policy is
>> again out of scope of this document. The FA should be released only
>> after the LSA associated with the FA is deleted throughout the
>> network. Once the LSA is deleted, the e2e LSPs routed over the FA are
>> expected to get rerouted around the FA. 5.1.3. Nest of FAs E2e LSP
>> can be tunneled into the PSC or non-PSC FA LSPs established between
>> GMPLS border nodes. Further nesting can also occur within the GMPLS
>> network (see [LSP-HIER]). Full mesh of PSC FA-LSPs may be created
>> between every border nodes using a set of non-PSC FA-LSPs across the
>> GMPLS-based transit region [MAMLTE]. The merit of this mechanism is
>> to attain the stability of MPLS-level routing, i.e., the forwarding
>> table of the LSR is kept intact even if the topology composed of a
>> set of non-PSC FA-LSPs are modified. There is not topology change
>> from the view point of MPLS-level. Traffic engi- neering is performed
>> by reconfiguring the virtual topology consisting of a set of non-PSC
>> FAs across the GMPLS-based transit region. Thanks to statistical
>> multiplexing gain, there is no waste of bandwidth resource even if a
>> PSC FA-LSP is created. 5.1.4. Virtual FA The virtual FA can be used
>> instead of the FA to allow the path across the GMPLS-based transit
>> region to be computed while avoiding waste of bandwidth and
>> adaptation port occupation by non-PSC FA. A set of the virtual FAs
>> forms the virtual topology for the best-effort and/or the
>> traffic-engineered route across the GMPLS-based transit region. The
>> virtual topology may be designed taking into account the (forecast)
>> traffic demand and available resource in the GMPLS-based transit
>> region. How to design the virtual topology is out of scope of [Page
>> 17] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt
>> July 2004 this document. The virtual topology may dynamically change
>> according to the change of the (forecast) traffic demand and the
>> available resource in the transit region. The virtual topology is
>> changed by setting up and/or tearing down the virtual FA. 5.2. LSP
>> converting/LSP stitching 5.2.1. One-to-one relationship LSP
>> converting and LSP stitching have common property when they are
>> applied to the reference model for MPLS-GMPLS-MPLS. There is a
>> one-to- one relationship between the e2e LSP and the transit segment.
>> When the e2e LSP is set up and/or torn down, the associated transit
>> segment is set up and/or torn down accordingly. Due to the one-to-one
>> relationship, these mechanisms are relevant only for MPLS - GMPLS
>> (PSC) -MPLS scenario. 5.2.2. Traffic demand change When the traffic
>> demand for the e2e LSP changes, the bandwidth allocated to the
>> transit segment may be modified. When the bandwidth is modified in
>> the SENDER_TSPEC/FLOWSPEC object, the LSP-ID field of SENDER_TEMPLATE
>> object for the e2e LSP is modified in both methods
>> (make-before-break, see [RFC3209]). This modification may trigger
>> the same LSP ID change for the transit segment if its bandwidth needs
>> to be readjusted. 6. Acknowledgements The authors are grateful to
>> Adrian Farrel for his numerous valuable com- ments. [Page 18] E. Oki
>> et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 7.
>> Security Considerations There are not security issues in this draft.
>> 8. References 8.1. Normative references [RFC3471] L. Berger et al.,
>> "Generalized MPLS - Signaling Functional Description", RFC 3471,
>> January 2003. [RFC3473] L. Berger et al., "Generalized MPLS Signaling
>> - RSVP-TE Exten- sions", RFC 3473, January 2003. [GMPLS-ARCH] E.
>> Mannie (Editor), "Generalized Multi-Protocol Label Switching
>> Architecture," <draft-ietf-ccamp-gmpls-architecture-07.txt> (Work in
>> progress), May 2003. [GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF
>> Extensions in Support of Generalized MPLS",
>> <draft-ietf-ccamp-ospf-gmpls-extensions-12.txt> (work in progress),
>> October 2003. [GMPLS-ISIS] "IS-IS extensions in support of
>> generalized multi-protocol label switching,"
>> <draft-ietf-isis-gmpls-extensions-19.txt> (work in progress), October
>> 2003. [GMPLS-LMP] J. Land, "Link management protocol (LMP),"
>> <draft-ietf- ccamp-lmp-10.txt> (work in progress), October 2003.
>> [PWE3] S. Bryant, P. Pate (Editors), "PWE3 Architecture,"
>> <draft-ietf- pwe3-arch-07.txt> (work in progress), March 2003.
>> [OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering
>> (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [OSPF]
>> J. Moy, "OSPF Version 2", RFC2328, April 1998. [Page 19] E. Oki et
>> al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 8.2.
>> Informative references [MRN] D. Papadimitriou, M. Vigoureux, K.
>> Shiomoto, D. Brungard. J.L. Le Roux, "Generalized MPLS Architecture
>> for Multi-Region Networks," <draft-
>> vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt> (work in progress),
>> February 2004. [GMPLS-ROUTING] K. Kompella and Y. Rekhter, "Routing
>> Extensions in Sup- port of Generalized Multi-Protocol Label
>> Switching," <draft-ietf-ccamp- gmpls-routing-09.txt> (work in
>> progress), October 2003. [Inter-domain] A. Farrel, J-P. Vasseur, and
>> A. Ayyangar, "A framework for inter-domain MPLS traffic engineering,"
>> <draft-farrel-ccamp-inter- domain-framework-00.txt> (work in
>> progress), April 2004. [HIER] K. Kompella and Y. Rekhter, "LSP
>> hierarchy with generalized MPLS TE,"
>> <draft-ietf-mpls-lsp-hierarchy-08.txt> (work in progress), Septem-
>> ber 2002. [RFC3477] K. Kompella and Y. Rekhter, "Signalling
>> Unnumbered Links in Resource ReSerVation Protocol -Traffic
>> Engineering (RSVP-TE)," RFC3477, January, 2003. [MAMLTE] K. Shiomoto
>> et al., "Multi-area multi-layer traffic engineering using
>> hierarchical LSPs in GMPLS networks," <draft-shiomoto-multiarea-
>> te-01.txt> (work in progress), June 2002. [P&R] J.P. Lang, Y.
>> Rekhter, D. Papadimitriou (Editors), "RSVP-TE Extensions in support
>> of End-to-End GMPLS-based Recovery", <draft-ietf-
>> ccamp-gmpls-recovery-e2e-signaling-01.txt> (work in progress), May
>> 2004. [GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the
>> Overlay Model," <draft-ietf-ccamp-gmpls-overlay-04.txt> (work in
>> progress), April 2004. [GMPLS-RECOVERY] CCAMP P&R Design Team,
>> "Analysis of Generalized Multi- Protocol Label Switching
>> (GMPLS)-based Recovery Mechanisms (including Protection and
>> Restoration)," <draft-ietf-ccamp-gmpls-recovery-analy- sis-03.txt>
>> (work in Progress), April 2004. [TE-INFO] Vasseur, J.P., Le Roux,
>> J.L., et al., "Routing extensions for discovery of TE router
>> information", <draft-vasseur-ccamp-te-router- info-00.txt> (work in
>> progress), July 2004. [INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP.
>> "Inter-domain MPLS traffic engineering RSVP extensions",
>> <draft-ayyangar-ccamp-inter-domain-rsvp- [Page 20] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 te-00.txt>
>> (work in progress), July 2004. [MPLS-FRR] Ping Pan et. at., "Fast
>> reroute extensions to RSVP-TE for LSP tunnels,"
>> <draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. (work in progress), May
>> 2004. [GMPLS-SR] Louis Berger, Igor Bryskin, Dimitri Papadimitriou,
>> Adrian Farrel, "GMPLS Based Segment
>> Recovery,"<draft-ietf-ccamp-gmpls-segment- recovery-00.txt> (work in
>> progress), March 2004. [INTER-AREA-REQ] Le Roux, J.L., Vasseur, J.P.,
>> Boyle, J., "Requirements for Inter-Area MPLS Traffic Engineering",
>> <draft-ietf-tewg-interarea- mpls-te-req-02.txt>, June 2004. 9.
>> Author's Address Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel
>> Ave. Middletown, NJ 07748, USA Phone: +1 732 420 1573 E-mail:
>> dbrungard@att.com Jean-Louis Le Roux France Telecom R&D av Pierre
>> Marzin 22300 Lannion France E-mail:
>> jeanlouis.leroux@francetelecom.com Eiji Oki NTT Midori 3-9-11
>> Musashino, Tokyo 180-8585, Japan E-mail: oki.eiji@lab.ntt.co.jp
>> Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018
>> Antwerpen, Belgium Phone : +32 3 240 8491 E-mail:
>> dimitri.papadimitriou@alcatel.be Daisaku Shimazaki NTT Midori 3-9-11
>> Musashino, Tokyo 180-8585, Japan [Page 21] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 E-mail:
>> shimazaki.daisaku@lab.ntt.co.jp Kohei Shiomoto NTT 3-9-11 Midori-cho,
>> Musashino-shi, Tokyo 180-8585, Japan E-mail:
>> shiomoto.kohei@lab.ntt.co.jp 10. Intellectual Property Rights
>> Notices The IETF takes no position regarding the validity or scope of
>> any intel- lectual property 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; neither does it represent that it
>> has made any effort to identify any such rights. Information on the
>> IETF's procedures with respect to rights in standards-track and
>> standards-related documentation can be found in BCP-11. Copies of
>> claims of rights made available for publication 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 implementors or users of this specification can
>> be obtained from the IETF Secretariat. The IETF invites any
>> interested party to bring to its attention any copyrights, patents or
>> patent applications, or other proprietary rights which may cover
>> technology that may be required to practice this stan- dard. Please
>> address the information to the IETF Executive Director. 10.1. IPR
>> Disclosure Acknowledgement By submitting this Internet-Draft, I
>> certify that any applicable patent or other IPR claims of which I am
>> aware have been disclosed, and any of which I become aware will be
>> disclosed, in accordance with RFC 3668. Full Copyright Statement
>> Copyright (C) The Internet Society (2003). All Rights Reserved. This
>> document and translations of it may be copied and furnished to oth-
>> ers, and derivative works that comment on or otherwise explain it or
>> assist in its implementation may be prepared, copied, published and
>> dis- tributed, in whole or in part, without restriction of any kind,
>> provided [Page 22] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 that the
>> above copyright notice and this paragraph are included on all such
>> copies and derivative works. However, this document itself may not
>> be modified in any way, such as by removing the copyright notice or
>> ref- erences to the Internet Society or other Internet organizations,
>> except as needed for the purpose of developing Internet standards in
>> which case the procedures for copyrights defined in the Internet
>> Standards process must be followed, or as required to translate it
>> into languages other than English. The limited permissions granted
>> above are perpetual and will not be revoked by the Internet Society
>> or its successors or assignees. This document and the information
>> contained herein is provided on an "AS IS" basis and THE INTERNET
>> SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 FIT- NESS FOR
>> A PARTICULAR PURPOSE. [Page 23] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July
>> 2004 Table of Contents Abstract . . . . .
>> . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conventions
>> used in this document . . . . . . . . . . . . . . . . . 2 1.
>> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
>> 2. Migration scenarii . . . . . . . . . . . . . . . . . . . . . .
>> . 3 2.1. MPLS-GMPLS(non-PSC)-MPLS . . . . . . . . . . . . . . . .
>> . . . 4 2.2. MPLS-GMPLS(PSC)-MPLS . . . . . . . . . . . . . . . .
>> . . . . . 5 2.3. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) . . . . . . .
>> . . . . . . . 5 2.4. GMPLS(PSC)-MPLS-GMPLS(PSC) . . . . . . . . .
>> . . . . . . . . . 6 3. Difference between MPLS and GMPLS protocols
>> . . . . . . . . . . . 6 3.1. Routing . . . . . . . . . . . . . . .
>> . . . . . . . . . . . . . 6 3.2. Signaling . . . . . . . . . . . .
>> . . . . . . . . . . . . . . . 7 3.3. Control plane/data plane
>> separation . . . . . . . . . . . . . 8 3.4. Bi-directional LSP .
>> . . . . . . . . . . . . . . . . . . . . . 9 4. Required mechanism
>> . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Routing . . .
>> . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1.
>> Single-area . . . . . . . . . . . . . . . . . . . . . . . . . 9
>> 4.1.1.1. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . .
>> 10 4.1.2. Multi-area . . . . . . . . . . . . . . . . . . . . . . . .
>> . 11 4.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . .
>> . . . 11 4.2.1. LSP nesting . . . . . . . . . . . . . . . . . . . .
>> . . . . . 13 4.2.2. LSP converting . . . . . . . . . . . . . . . .
>> . . . . . . . 13 4.2.2.1. MPLS->GMPLS . . . . . . . . . . . . . . .
>> . . . . . . . . . 13 4.2.2.2. GMPLS->MPLS . . . . . . . . . . . . .
>> . . . . . . . . . . . 14 4.2.2.3. ERO/RRO processing . . . . . . .
>> . . . . . . . . . . . . . 14 4.2.3. LSP stitching . . . . . . . . .
>> . . . . . . . . . . . . . . . 15 4.2.4. Discovery of GMPLS
>> signalling capability . . . . . . . . . . 15 5. MPLS-GMPLS-MPLS
>> reference model . . . . . . . . . . . . . . . . . 16 5.1. LSP
>> nesting . . . . . . . . . . . . . . . . . . . . . . . . . . 16
>> 5.1.1. Basic description . . . . . . . . . . . . . . . . . . . . . .
>> 16 5.1.2. Traffic demand change . . . . . . . . . . . . . . . . . . .
>> . 16 5.1.3. Nest of FAs . . . . . . . . . . . . . . . . . . . . . .
>> . . . 17 5.1.4. Virtual FA . . . . . . . . . . . . . . . . . . . .
>> . . . . . 17 5.2. LSP converting/LSP stitching . . . . . . . . . .
>> . . . . . . . 18 5.2.1. LSP One-to-one relationship . . . . . . . .
>> . . . . . . . . . 18 5.2.2. LSP Traffic demand change . . . . . . .
>> . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . .
>> . . . . . . . . . . . . . 18 7. Security Considerations . . . . . .
>> . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . .
>> . . . . . . . . . . . . . . . . . 19 8.1. Normative references . .
>> . . . . . . . . . . . . . . . . . . . 19 8.2. Informative
>> references . . . . . . . . . . . . . . . . . . . . 20 9. Author's
>> Address . . . . . . . . . . . . . . . . . . . . . . . . 21 10.
>> Intellectual Property Rights Notices . . . . . . . . . . . . . . 22
>> 10.1. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . .
>> 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .
>> . 22 [Page 1] E. Oki et al.
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 [Page 2]
>> .pl 10.0i
>> .po 0
>> .ll 7.2i
>> .lt 7.2i
>> .nr LL 7.2i
>> .nr LT 7.2i
>> .ds LF
>> .ds RF [Page %]
>> .ds CF
>> .ds LH E. Oki et al.
>> .ds RH July 2004
>> .ds CH draft-oki-ccamp-gmpls-ip-interworking-03.txt
>> .ad l
>> .in 0
>> .nh
>> .hy 0
>>
>> .nf
>> CCAMP Working Group Deborah Brungard (AT&T)
>> Internet Draft Jean-Louis Le Roux (France Telecom)
>> Expiration Date: December 2004 Eiji Oki (NTT)
>> Dimitri Papadimitriou (Alcatel)
>> Daisaku Shimazaki (NTT)
>> Kohei Shiomoto (NTT)
>>
>>
>>
>> July 2004
>>
>> .ce
>> Migrating from IP/MPLS to GMPLS networks
>>
>> .ce
>> draft-oki-ccamp-gmpls-ip-interworking-03.txt
>>
>> .ti 0
>> Status of this Memo
>>
>> .fi
>> .in 3
>> This document is an Internet-Draft and is in full conformance with all
>> provisions of Section 10 of RFC2026.
>>
>> 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.
>>
>>
>> By submitting this Internet-Draft, I certify that any applicable patent
>> or other IPR claims of which I am aware have been disclosed, and any of
>> which I become aware will be disclosed, in accordance with RFC 3668.
>>
>> .ti 0
>> Copyright Notice
>>
>> Copyright (C) The Internet Society (2004). All Rights Reserved.
>>
>> .SH
>> Abstract
>> .XS
>> Abstract
>> .XE
>>
>> This document is addressing the migration from Multi-protocol label
>> switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to
>> expand the capacity of the existing MPLS-based infrastructure
>> network, the optical network
>> consisting of L2SC, TDM, LSC, and FSC devices
>> will be deployed, which is controlled by the GMPLS protocols. GMPLS
>> protocols are, however,
>> subtly different from MPLS protocols. In this document we describe
>> possible migration scenarii,
>> the mechanisms to compensate the difference between MPLS and GMPLS
>> protocols, and how the mechanisms are applied to
>> migrate from the MPLS to the GMPLS network.
>>
>> .SH
>> Conventions used in this document
>> .XS
>> Conventions used in this document
>> .XE
>>
>>
>> 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.
>>
>>
>>
>> .NH 1
>> Introduction
>> .XS
>> \*(SN Introduction
>> .XE
>>
>>
>> Multi-protocol label switching (MPLS) is widely deployed with
>> applications such as traffic
>> engineering and virtual private network (VPN). Various kinds of
>> services such as VoIP, IPv6,
>> L2VPN/L3VPN, pseudo wire emulation are expected to be converged over
>> the MPLS-based
>> infrastructure network.
>>
>> Traffic volume is tremendously increasing as broadband service
>> enabled by ADSL and
>> FTTH is rapidly penetrating the market and the processing performance
>> of terminal and
>> server is ever increasing. In order to cope with such increase of the
>> traffic volume, optical networks, which consists of L2SC, TDM, LSC,
>> and FSC devices, will be
>> introduced.
>>
>> Generalized MPLS (GMPLS) is being standardized by extending MPLS to
>> control such
>> optical networks (see [RFC3471], [RFC3473], [GMPLS-ROUTING],
>> [GMPLS-OSPF], [GMPLS-ISIS], [GMPLS-LMP]). GMPLS
>> network will be deployed as a part of the existing MPLS
>> infractructure. MPLS and GMPLS devices
>> will coexist in the network until the existing MPLS network is
>> completely migrated to the
>> GMPLS network.
>>
>> GMPLS protocols are, however, subtly extending MPLS protocols'
>> capabilities. 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 scenarii from MPLS to GMPLS networks, the mechanisms to
>> compensate the
>> difference between MPLS and GMPLS, and the applicability of the
>> mechanisms to the
>> possible migration scenarii.
>>
>> We should note that GMPLS covers Packet Switching Capable (PSC)
>> networks [GMPLS-ARCH].
>> In the rest of this document, when dealing with GMPLS, it means both
>> PSC and non-PSC.
>> Otherwise PSC GMPLS or non-PSC GMPLS is explicitly mentioned.
>>
>>
>> GMPLS introduces new features such as bidirectional LSPs, label
>> suggestion, label restriction, graceful restart, graceful teardown,
>> and forwarding adjacencies (see [GMPLS-ARCH]).
>> Also several features are provided in a distinct manner. For instance
>> local protection is provided using distinct mechanisms in MPLS (see
>> [MPLS-FRR]) and GMPLS (see [GMPLS-SR]).
>> Migration from MPLS to GMPLS should bring these features and such
>> distinct mechanisms in the existing MPLS-based infrastructure network.
>>
>>
>>
>> The rest of this document is organized as follows.
>> In Section 2, we taxonomize the migration scenarii from MPLS to GMPLS
>> networks.
>> In Section 3, we describe the problems caused by the difference
>> between MPLS and GMPLS protocols.
>> In Section 4, we present the required mechanisms, which bridge the
>> difference between MPLS and GMPLS protocols.
>> Some of those mechanisms are available today and others are not.
>> In Section 5, we present the applicability of the required mechanisms
>> to a reference network model for
>> the migration from MPLS to GMPLS networks.
>>
>> .NH 1
>> Migration scenarii
>> .XS
>> \*(SN Migration scenarii
>> .XE
>>
>> Two categories of migration scenarii are considered: (1)
>> MPLS-GMPLS-MPLS and (2)
>> GMPLS-MPLS-GMPLS. In case of (1) MPLS-GMPLS-MPLS scenario, source and
>> destination nodes of the Label Switched path (LSP) are in MPLS and a
>> set of its intermediate nodes take part of GMPLS. In case of (2)
>> GMPLS-MPLS-GMPLS scenario, LSP
>> source and destination nodes are in GMPLS network and a set of its
>> intermediate nodes take part of MPLS network. Each category is
>> subdivided in two sub-categories as to whether GMPLS is PSC or non-PSC.
>>
>> MPLS-GMPLS (PSC) migration scenario, where LSP start/end in an MPLS
>> network and end/start in a GMPLS PSC network, will be addressed in a
>> future revision.
>>
>>
>> .NH 2
>> MPLS-GMPLS(non-PSC)-MPLS
>> .XS
>> \*(SN MPLS-GMPLS(non-PSC)-MPLS
>> .XE
>>
>>
>>
>> Introduction of a GMPLS-based optical core network to increase the
>> capacity is an example of this category. TDM, LSC, and/or FSC LSPs
>> are established between MPLS networks across the GMPLS network.
>> A set of those LSPs
>> provide virtual network topology for MPLS networks.
>> This topology may be
>> reconfigurable by adding and/or removing those LSPs [MRN]. MPLS LSRs
>> and subnetworks
>> interconnected at
>> the edges of the virtual network topology may form a single MPLS
>> network.
>>
>> Figure 1 shows the reference network model for the
>> MPLS-GMPLS(non-PSC)-MPLS migration.
>> The reference network model consists of three regions: ingress,
>> transit, and egress.
>> Both the ingress and egress regions are MPLS-based while the transit
>> region is GMPLS-based.
>> The nodes at the boundary of the MPLS and GMPLS regions (G1, G2, G5,
>> and G6) are referred
>> to as "border node" hereafter.
>> All nodes except the border nodes in the GMPLS-based transit region
>> (G3 and G4)
>> are non-PSC device, i.e., optical equipment (TDM, LSC, and FSC).
>> An MPLS LSP can be provisioned from
>> a node in the ingress MPLS-based region (say, R2) to a node in the
>> egress MPLS-based region (say, R4).
>> The LSP is referred to as the "e2e" LSP hereafter.
>> The switching capability of both end points of e2e LSP are the same
>> (PSC).
>>
>> .KS
>> ................. .............................. ..................
>> : MPLS : : GMPLS (non-PSC) : : MPLS :
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> : ________/ : : ________/ | ________/ : : ________/ :
>> :| / : : / | / : : / :
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :................: :...........................: :................:
>>
>> |<-------------------------------------------------------->|
>> e2e LSP
>>
>> Figure 1 MPLS-GMPLS(non-PSC)-MPLS migration model.
>> .KE
>>
>>
>>
>> .NH 2
>> MPLS-GMPLS(PSC)-MPLS
>> .XS
>> \*(SN MPLS-GMPLS(PSC)-MPLS
>> .XE
>>
>> MPLS-based converged network can be migrated to GMPLS (PSC)-based
>> converged
>> network.
>> The rationale of this type of migration scenario is supported by two
>> factors:
>> (1) GMPLS-based advanced feature,
>> (2) stepwise migration for the GMPLS-based optical core network.
>> Regarding the GMPLS-based
>> advanced feature, numerous features are being developed in GMPLS
>> context (and
>> MPLS) including bi-directional LSP, label control, graceful restart,
>> graceful teardown
>> and forwarding adjacencies.
>> Existing
>> MPLS-based converged network could be migrated to GMPLS (PSC)-based
>> converged
>> network to deliver the advanced features. Once the PSC network is
>> migrated to
>> GMPLS-based one, it could be migrated to GMPLS-based optical core
>> network with
>> less effort.
>>
>>
>>
>>
>> .NH 2
>> GMPLS(non-PSC)-MPLS-GMPLS(non-PSC)
>> .XS
>> \*(SN GMPLS(non-PSC)-MPLS-GMPLS(non-PSC)
>> .XE
>>
>> In this scenario, TDM, L2SC e2e LSPs are provisioned in the GMPLS
>> network, which is partly disconnected.
>> In case the MPLS-based infrastructure network is widely deployed,
>> it is used to bridge the disconnected GMPLS networks.
>> Moreover, pseudo wire emulation is used edge-to-edge in the
>> MPLS-based converged network to
>> carry those LSPs [PWE3].
>>
>> Figure 2 shows the reference network model for the
>> GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration.
>> The reference network model consists of three regions: ingress,
>> transit, and egress.
>> Both the ingress and egress regions are GMPLS-based while the transit
>> region is MPLS-based.
>> The nodes at the boundary of the MPLS and GMPLS regions (G3, G4, G5,
>> and G6) are referred
>> to as "border node" hereafter.
>> All nodes except the border nodes in the GMPLS-based regions (G1,
>> G11, G2, G21, G71, G7, G81, and G8)
>> are non-PSC devices.
>> A GMPLS LSP can be provisioned from a node in the ingress GMPLS-based
>> region (say, G2)
>> to a node in the egress GMPLS-based region (say, G8).
>> The LSP is referred to as the "e2e" LSP hereafter.
>> The switching capability of both end points of e2e LSP must be the same.
>>
>> .KS
>>
>> .................. ............................. ..................
>> : GMPLS(non-PSC) : : MPLS : : GMPLS(non-PSC) :
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :|G1 |__|G11|___|G3 |__________|R1 |__________|G5 |___|G71|__|G7 |:
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> : ________/ : : ________/ | ________/ : : ________/ :
>> :| / : : / | / : : / :
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> :|G2 |__|G21|___|G4 |__________|R2 |__________|G6 |___|G81|__|G8 |:
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :................: :...........................: :................:
>>
>> |<-------------------------------------------------------->|
>> e2e LSP
>>
>> Figure 2 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration model.
>> .KE
>>
>>
>>
>> .NH 2
>> GMPLS(PSC)-MPLS-GMPLS(PSC)
>> .XS
>> \*(SN GMPLS(PSC)-MPLS-GMPLS(PSC)
>> .XE
>>
>> In this scenario, GMPLS PSC e2e LSPs are provisioned in the GMPLS
>> network, which is partly disconnected.
>> In case the MPLS-based infrastructure network is widely deployed,
>> it is used to bridge the disconnected GMPLS networks.
>> Since MPLS-based network is PSC,
>> the GMPLS PSC LSP can cross MPLS-based converged network without
>> extra treatment in
>> data plane.
>>
>>
>>
>> .NH 1
>> Difference between MPLS and GMPLS protocols
>> .XS
>> \*(SN Difference between MPLS and GMPLS protocols
>> .XE
>>
>>
>> .NH 2
>> Routing
>> .XS
>> \*(SN Routing
>> .XE
>>
>> In this document we assume that the OSPF-TE is used as IGP-TE.
>> However the IGP-TE description should apply to both IS-IS and OSPF.
>> Specifics concerning IS-IS will be detailed in the next release of
>> this document.
>>
>>
>> TE-link information is advertised in link state advertisement.
>> It allows collecting the whole topology information, which is stored in
>> traffic-engineering data base (TEDB).
>> Best-effort route and/or traffic-engineered explicit route for the
>> destination are
>> calculated using the TEDB.
>>
>> GMPLS extends the set of sub-TLVs for TE-link advertisements. Non-PSC
>> TE-link information used in
>> GMPLS is not supported by MPLS. Even PSC TE-link information used in
>> GMPLS is not fully
>> supported by MPLS (this is particularly the case for the Interface
>> Switching Capability Descriptor sub-TLV).
>> As a result, one cannot compute
>> traffic-engineered explicit route if they are travelling through both
>> MPLS and GMPLS
>> regions.
>>
>> Figure 3 illustrates the problem of mismatch of TE-link information
>> in MPLS and GMPLS.
>> Suppose that an e2e LSP is provisioned between R2 and R4 and that we
>> need to compute the path
>> between R2 and R4 (say, R2-R21-G2-G4-G6-R41-R4).
>> The TE link information for the links R2-R21, R21-G2, G6-R41 and
>> R41-R4 is MPLS-based TE link LSA, while the ones for the links G2-G4
>> and G4-G6 is GMPLS-based.
>> The node in MPLS-based ingress region (say, R2) cannot compute the
>> path, which consists of mixture of MPLS-based and GMPLS-based TE link
>> information.
>>
>> .KS
>> ................. .............................. ..................
>> : 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 3 Problem mismatch of TE-link information in MPLS and GMPLS
>> .KE
>>
>> Except for Opaque-LSA associated with TE-link, MPLS and GMPLS use the
>> same set of LSAs,
>> e.g., router-LSA, network-LSA, summary-LSA and etc. These LSAs in GMPLS
>> network construct the topology database of the control plane of GMPLS
>> network.
>>
>>
>>
>> .NH 2
>> Signaling
>> .XS
>> \*(SN Signaling
>> .XE
>>
>>
>> GMPLS RSVP-TE signalling ([RFC 3473]) introduces new objects, and
>> their associated procedures, that can not be processed/inserted by
>> MPLS LSRs:
>> .IP -
>> 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.
>> .IP -
>> 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.
>> .IP -
>> The Suggested Label Object, used to reduce LSP setup delays.
>> .IP -
>> The Label Set Object, used to restrict label allocation to a set of
>> label, which (particularly useful for wavelength conversion incapable
>> nodes)
>> .IP -
>> The Upstream Label Object, used for bidirectional LSP setup (see also
>> 3.4)
>> .IP -
>> The Restart Cap object, used for graceful restart.
>> .IP -
>> The Admin Status object, used for LSP administration, and
>> particularly for graceful LSP teardown.
>>
>>
>> .NH 2
>> Control plane/data plane separation
>> .XS
>> \*(SN Control plane/data plane separation
>> .XE
>>
>>
>> TDM, LSC, FSC networks do not recognize packet delineation. In GMPLS,
>> the control
>> channel can be logically (in-band) or physically (out-of-band)
>> separated from the data channel in those networks. The control channels
>> between adjacent nodes constitute a control plane network. Control
>> packets of routing
>> and signaling protocols are transmitted over the control plane network.
>>
>> If the GMPLS network consists of only PSC devices,
>> there can be no control plane/data plane separation.
>> All control packets share the same network links with data packets.
>> If the GMPLS
>> network consists of non-PSC devices,
>> there is at least a logical C/D separation at
>> least between PSC device and non-PSC device in GMPLS networks and
>> between non-PSC and non-PSC devices.
>>
>>
>> The GMPLS control plane,
>> which is designed to carry the control packet in GMPLS network, is
>> not likely to have enough
>> capacity to carry the user-data traffic from MPLS network.
>> Therefore, the control plane must ensure is it not carrying data
>> traffic from the MPLS network (see [GMPLS-ROUTING]).
>>
>>
>> .NH 2
>> Bi-directional LSP
>> .XS
>> \*(SN Bi-directional LSP
>> .XE
>>
>>
>> Since GMPLS supports TDM, LSC, and FSC switching and LSP classes,
>> which are mainly bi-directional
>> channels,
>> it also provides bi-directional LSP setup. In a single signaling
>> session, bi-directional
>> LSPs can be created along the same route in GMPLS network. On the
>> other hand,
>> there is no equivalent mechanism to support bi-directional LSPs in
>> MPLS network. The forward
>> and backward LSPs are created in different signaling sessions. The
>> route taken by
>> those LSPs may be different from each other. Their sessions are
>> treated differently
>> from each other.
>>
>> If MPLS and GMPLS networks are inter-connected, the bi-directional
>> LSPs from
>> GMPLS network need to be carried in MPLS network, which does not support
>> bi-directional LSP setup. At least we need a mechanism allowing to
>> route the forward and backward LSPs on the
>> same route.
>>
>>
>>
>>
>>
>> .NH 1
>> Required mechanism
>> .XS
>> \*(SN Required mechanism
>> .XE
>>
>>
>> In this section, we present at set of routing and signalling
>> mechanisms, in order to bridge the difference between MPLS and GMPLS
>> protocols.
>>
>> This section only proposes mechanisms for MPLS-GMPLS-MPLS migration.
>> GMPLS-MPLS-GMPLS (using PWE3 stuff) is for further study.
>>
>> .NH 2
>> Routing
>> .XS
>> \*(SN Routing
>> .XE
>>
>>
>> The entire network consisiting of ingress, transit, and egress
>> regions (See Fig.1 or 2 for instance) may be either single-area or
>> multi-area from the IGP perspective.
>>
>> .NH 3
>> Single-area
>> .XS
>> \*(SN Single-area
>> .XE
>>
>>
>> If the entire network is a single-area, the partial topology of
>> GMPLS-based region, which is consisting of PSC-link, should be
>> visible to MPLS regions.
>> GMPLS TE-links are advertised as MPLS TE-links using MPLS-based TE
>> link information to the MPLS networks so that node in the MPLS region
>> can understand the GMPLS TE-links. This requires some TE-link
>> information conversion.
>>
>> If the GMPLS-based region consists of only non-PSC devices except the
>> border nodes, PSC-links should be set up between the border nodes.
>> For example, in Fig. 3, a PSC-link can be set up between G2 and G6.
>> PSC-links are advertised as the forwarding adjacency (FA) in the
>> GMPLS- based region.
>> The e2e LSP can be tunnelled through the FA [HIER].
>> In the MPLS to GMPLS migration scenarii, FA should be advertised as
>> TE-links in the MPLS regions, using MPLS-based TE-link information.
>>
>> A set of FAs across the GMPLS region provides the virtual network
>> topology (VNT), which can be reconfigured by creating and/or
>> destroying FAs, to MPLS regions. See [MRN] for details.
>>
>> MPLS TE-links MAY be understood by the nodes in the GMPLS network,
>> which can transform MPLS-based TE-link information into GMPLS-based
>> TE-link information.
>>
>> .NH 4
>> Virtual FA
>> .XS
>> \*(SN Virtual FA
>> .XE
>>
>> If the entire network consists of a single IGP area and the
>> GMPLS-based region consists of only non-PSC devices except the border
>> nodes, FAs should be set up between the GMPLS border nodes.
>> To avoid unnecessary bandwidth consumption non-PSC FA LSP should be
>> created only if there exists traffic demand between the end points.
>>
>> In order to compute the path across the GMPLS region, the FA-LSP must
>> be set up for being advertized as per [HIER].
>> The "virtual" FA-LSP is defined here to cope with the situation.
>> The virtual FA-LSP is not instantiated but is advertised as a TE-link
>> by routing protocol to attract traffic.
>> The virtual FA may be provisioned using the similar method for
>> provisioning the secondary LSP in the shared mesh restoration
>> scheme [P&R].
>> Or the virtual FA may be just signalled between both end points
>> without having the transit nodes intervene.
>>
>> A set of virtual FAs forms the virtual topology for the best-effort
>> and/or the traffic-engineered route across the GMPLS region. The virtual
>> topology may be designed taking into account the (forecast) traffic
>> demand and the available resource in the transit region. The virtual
>> topology may dynamically change according to the variation of the
>> (forecast) traffic demand and the available resource in the transit
>> region to
>> optimize the tradeoff between network performance and the residual
>> network capacity. How to design the virtual topology and its changes
>> is out of scope of this document.
>>
>>
>> The virtual topology is changed by setting up and/or tearing down
>> virtual FA-LSP.
>> Signaling messages are used to exchange the link identifiers in a
>> similar way of the FA as described in [RFC3477] and [LSP-
>> HIER].
>> Unlike the case of FA-LSP, the intermediate nodes may not be involved
>> in signaling message processing when the virtual FA-LSP is not
>> provisioned (Just link interface identifiers are exchanged by
>> signaling between ingress and egress nodes).
>> Both unnumbered and numbered virtual FAs should be defined.
>>
>> There is no routing adjacency along the (virtual) FA. There is no
>> hello packets exchanged between the end points of the (virtual) FA.
>>
>> When an e2e MPLS LSP is setup through a virtual FA, this should
>> trigger the setup of a real FA-LSP is the GMPLS network.
>>
>>
>>
>> .NH 3
>> Multi-area
>> .XS
>> \*(SN Multi-area
>> .XE
>>
>> A simple migration approach can also consist in separating MPLS and
>> GMPLS networks into distinct IGP areas, and then rely
>> on multi-area routing, path computation, and signaling solutions
>> under specification in CCAMP WG (ABR acting as a Path Computation
>> Element for instance).
>> Basicaly there is no backward compatibility issue when MPLS and GMPLS
>> LSRs resides in disctinct IGP areas, as TE-link information is not
>> leaked across area (see see [INTER-AREA-REQ] and [INTER-Domain]).
>>
>>
>>
>> .NH 2
>> Signaling
>> .XS
>> \*(SN Signaling
>> .XE
>>
>> We describe the signaling mechanisms, which can be applied to the
>> migration scenarii from MPLS to GMPLS.
>> Three basic cases for the MPLS-GMPLS-MPLS environment are described
>> in Fig. 4: LSP nesting, LSP converting, and LSP stitching.
>>
>> LSP nesting: One or more packet LSPs is nested into one LSP.
>>
>> LSP converting: The end-to-end packet LSP signaling messages (RFC
>> 3209) is translated at the GMPLS borders into GMPLS RSVP-TE (see RFC
>> 3473).
>> The GMPLS RSVP-TE segment MUST also be PSC.
>> This case requires a service interworking function 3209/3473 (at the
>> control plane level).
>>
>> LSP stitching: A segment PSC LSP is stitched within an end-to-end
>> packet LSP.
>> This case does require a network interworking function (at the
>> control plane level) since MPLS signaling messages are directed
>> between GMPLS border nodes.
>>
>>
>> .KS
>> ................. .............................. ..................
>> : MPLS : : GMPLS (PSC) : : MPLS :
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> : ________/ : : ________/ | ________/ : : ________/ :
>> :| / : : / | / : : / :
>> :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
>> :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
>> :+---+ +---+ +---+ +---+ +---+ +---+ +---+:
>> :................: :...........................: :................:
>>
>> session for e2e LSPs
>> |<-------------------------------------------------------->|
>> |<-------------------------------------------------------->|
>> |<-------------------------------------------------------->|
>> session for FA/LSP tunnel
>> |<-------------------------->|
>> e2e LSP _____________________________
>> <------------ | FA/LSP tunnel | ----------->
>> <------------ | | ----------->
>> <------------ | | ----------->
>> |_____________________________|
>>
>> (a) LSP nesting
>>
>>
>> e2e session
>> |<-------------------------------------------------------->|
>> ____________ ____________________________ ____________
>> | MPLS seg. || GMPLS segment || MPLS seg. |
>> |____________||____________________________||____________|
>>
>> (b) LSP converting
>>
>>
>> e2e session
>> |<-------------------------------------------------------->|
>> transit session
>> |<-------------------------->|
>> ____________ ____________________________ ____________
>> | MPLS seg. || GMPLS segment || MPLS seg. |
>> |____________||____________________________||____________|
>>
>> (c) LSP stitching
>>
>> Figure 4 Comparisons of signaling in MPLS-GMPLS-MPLS migration model.
>> .KE
>>
>>
>> .NH 3
>> LSP nesting
>> .XS
>> \*(SN LSP nesting
>> .XE
>>
>> Figure 4 (a) illustrates the LSP nesting in the MPLS-GMPLS-MPLS
>> reference network model.
>> An FA-LSP is created by setting up the FA-LSP.
>> FA is established between the boundary of the ingress and the
>> transit regions and that of the transit and the egress regions.
>> Three e2e LSPs are provisioned between the nodes in the MPLS-based
>> ingress region (say, R2) and egress region (say, R4).
>> These e2e LSPs are tunnelled inside the same FA-LSP across the
>> transit region.
>>
>> LSP nesting is different from the LSP stitching and the LSP
>> converting with respect to data
>> plane. The e2e LSP is nested inside the FA while there is no nesting
>> in the LSP
>> stitching and the LSP converting. Multiple e2e LSPs can be nested
>> inside a single FA-LSP.
>> Scalability is hereby attained.
>>
>> There exist at least two sessions: one for the FA-LSP and the others
>> for e2e LSP(s).
>> Along the FA-LSP, the state is created and maintained during the
>> life-time of the FA-LSP.
>> When the FA-LSP is re-routed (for example due to re-optimization,
>> failure recovery, etc.), the FA link is not impacted as
>> long as the alternative FA-LSP exists.
>>
>> FA-LSP mechanism applies to MPLS-GMPLS (non PSC)-MPLS and MPLS-GMPLS
>> (PSC)-MPLS migration scenarii.
>>
>>
>>
>> .NH 3
>> LSP converting
>> .XS
>> \*(SN LSP converting
>> .XE
>>
>> LSP can be converted from MPLS to GMPLS and vice versa at the
>> boundary of MPLS
>> and GMPLS regions while remaining in the same session.
>> This is achieved by delivering an interworking function at the
>> control plane of the GMPLS border nodes.
>> Figure 4 (b) illustrates the LSP converting in the MPLS-GMPLS-MPLS
>> reference network model.
>> The e2e LSP is provisioned between the nodes in the MPLS-based
>> ingress region (say, R2) and egress region (say, R4).
>> The e2e LSP consists of three segments: ingress, transit, egress.
>> The transit segment is GMPLS-based and therefore it is referred to as
>> GMPLS-segment while others are referred to as MPLS-segments.
>> The e2e LSP is associated with the single session, which is referred
>> to as the "e2e" session.
>> This is relevant only for MPLS-GMPLS (PSC)-MPLS migration scenario.
>>
>> .NH 4
>> MPLS->GMPLS
>> .XS
>> \*(SN MPLS->GMPLS
>> .XE
>>
>> LSP is converted from MPLS to GMPLS at the boundary of MPLS ingress and
>> GMPLS transit regions. In case of C/D separation in the GMPLS transit
>> region, the signaling message is separated from the data plane network
>> at the boundary.
>>
>> Regarding the control plane, the signaling message associated with the
>> e2e LSP is carried in the control plane network in the GMPLS transit
>> region. Appropriate objects newly defined for GMPLS (say, Generalized
>> label request object) is attached to the signaling message.
>>
>>
>>
>> .NH 4
>> GMPLS->MPLS
>> .XS
>> \*(SN GMPLS->MPLS
>> .XE
>>
>> LSP is converted from GMPLS to MPLS at the boundary of GMPLS transit and
>> MPLS egress regions. In case of C/D separation in the GMPLS transit
>> region, the signaling message from the data plane network is multiplexed
>> to the data plane message at the boundary. LSP is converted with
>> respect to both the control and the data plane aspects.
>>
>>
>> Regarding the control plane aspect, the signaling message objects, which
>> are not supported by MPLS, are lost. The associated functions are not,
>> therefore, effective in MPLS network accordingly. GMPLS-segment is
>> either uni-directional or bi-directional. There is no mechanism to set
>> up the bi-directional MPLS LSPs within the same session along the same
>> route.
>>
>>
>>
>> .NH 4
>> ERO/RRO processing
>> .XS
>> \*(SN ERO/RRO processing
>> .XE
>>
>> There are three cases depending on the level of detail of the transit
>> segment specified as part of the EROs issued in the Path message
>> issued by the ingress of the e2e LSP.
>>
>> .IP 1)
>> The ERO issued by the ingress of the e2e LSP includes the tail-end of
>> the transit segment as a strict subobject.
>> Then, if the head-end of the transit segment is also included as a
>> strict node, in this case ERO processing follows rules described in
>> Section 8.2 of [LSP-HIER] as the sequence of the transit segment is
>> complete once issued by the ingress of the e2e LSP.
>> Otherwise, if the head-end node of the transit segment (or any other
>> subobject preceding the tail-end) is specified as a loose subobject,
>> the preceding strict node inserts the sequence of subobjects within
>> the ERO as specified in [RFC 3209] to reach the next loose node.
>> .IP 2)
>> The ERO issued by the ingress of the e2e LSP includes both head-
>> (strict or loose) and tail-end (loose) of the transit segment. In
>> this case, the ingress GMPLS border node inserts sequence of
>> subobjects within the ERO as specified in [RFC 3209] to reach the
>> egress border node.
>> .IP 3)
>> The ERO issued by the ingress of the e2e LSP does not include the
>> tail-end of the transit segment.
>> In this case, the ingress border node should decide the exit point to
>> reach the next loose node being outside of the transit region.
>>
>> .LP
>> RROs in the transit segment may carry the nodes in the transit
>> region. The nodes in the
>> transit segment may be removed from the RROs when they depart from
>> the transit region.
>> The ingress and egress border nodes should be included in the RROs
>> when they are carried
>> in the ingress and the egress regions.
>>
>>
>>
>> .NH 3
>> LSP stitching
>> .XS
>> \*(SN LSP stitching
>> .XE
>>
>> LSP can be stitched at the boundary of MPLS and GMPLS regions
>> [Inter-domain].
>> The LSP stretches from the ingress through the transit to the egress
>> regions.
>> Figure 4 (c) illustrates the LSP stitching in the MPLS-GMPLS-MPLS
>> reference network model.
>> The e2e LSP is provisioned between the nodes in the MPLS-based
>> ingress region (say, R2) and egress region (say, R4).
>> The e2e LSP consists of two segments: ingress/egress and transit.
>> The transit segment is GMPLS-based and therefore it is referred to as
>> GMPLS-segment while others are referred to as MPLS-segments.
>> The e2e LSP is associated with the two sessions: one for the entire
>> stretch (i.e., ingress to egress regions)
>> and the other for the transit segment.
>> The signaling mechanisms described in [INTER-DOMAIN-SIG] can be applied.
>>
>> .NH 3
>> Discovery of GMPLS signalling capability
>> .XS
>> \*(SN Discovery of GMPLS signalling capability
>> .XE
>>
>> I may be useful to advertise into the IGP the capability of a node to
>> support GMPLS signalling. This would allow every node in the network
>> to automatically discover the GMPLS signalling regions. [TE-INFO]
>> provides a functional description of routing extensions in order to
>> advertise TE router information, including Control Plane Capabilities
>> such as GMPLS signaling.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> .NH 1
>> MPLS-GMPLS-MPLS reference model
>> .XS
>> \*(SN MPLS-GMPLS-MPLS reference model
>> .XE
>>
>> In this section, the required mechanisms with the MPLS-GMPLS-MPLS
>> reference network model is discussed.
>> FA/LSP tunnel, LSP converting, and LSP stiching are applied to the
>> reference network model.
>>
>> From Figure 1, we consider that the packet LSP is set up between the
>> ingress and the egress regions. The LSP is
>> referred to as "e2e" LSP hereafter. The LSP portion corresponding to
>> the transit
>> GMPLS-base region is referred to as "transit segment". The transit
>> segment is
>> implemented by either (1) LSP nesting, (2) LSP converting, or (3) LSP
>> stitching.
>>
>>
>> .NH 2
>> LSP nesting
>> .XS
>> \*(SN LSP nesting
>> .XE
>>
>> .NH 3
>> Basic description
>> .XS
>> \*(SN Basic description
>> .XE
>>
>> FAs are created between the GMPLS border nodes.
>> The FAs are advertised in the MPLS regions, by the routing protocol,
>> using MPLS TE-link information ([OSPF-TE] or [ISIS-TE]).
>>
>> The e2e LSP is tunneled through the FA across the GMPLS-based transit
>> region.
>> Multiple e2e LSPs may be tunnelled through a single FA. The e2e LSP
>> may be carried over
>> multiple hops of FAs across the GMPLS-based transit region unless
>> there is no direct
>> FA between the ingress and the egress regions.
>>
>>
>> .NH 3
>> Traffic demand change
>> .XS
>> \*(SN Traffic demand change
>> .XE
>>
>> Traffic demand may change after the FA is created. Some FAs, which do
>> not carry any
>> e2e LSP any longer may be released for resource release. They may
>> be also retained for future usage.
>> Release or retention of underutilized FAs is a policy decision.
>> Detail of the policy is out of scope of this document.
>>
>> FAs may be created based on the policy, which might consider residual
>> resource in
>> GMPLS-based transit region and the change of traffic demand. By
>> creating the new
>> FAs, the network performance such as maximum residual capacity may be
>> improved.
>>
>> As the number of FAs grows, the residual resource in the GMPLS-based
>> transit region
>> may decrease. In this case, re-optimization may be invoked in the
>> GMPLS-based
>> transit region according the the policy. Detail of the policy is
>> again out of scope of this
>> document.
>>
>> As part of the reoptimization process, FA-LSPs may be rerouted while
>> keeping interface identifiers of FA links unchanged. However, the
>> routing in
>> MPLS level should be unaffected since there is no change of topology
>> composed of FAs across
>> the GMPLS-based transit region.
>>
>> When residual resource in the GMPLS-based transit region decreases,
>> some FAs may
>> be released according to the policy. Detail of the policy is again
>> out of scope of this
>> document. The FA should be released only after the LSA associated
>> with the FA is
>> deleted throughout the network. Once the LSA is deleted, the e2e LSPs
>> routed over
>> the FA are expected to get rerouted around the FA.
>>
>> .NH 3
>> Nest of FAs
>> .XS
>> \*(SN Nest of FAs
>> .XE
>>
>> E2e LSP can be tunneled into the PSC or non-PSC FA LSPs established
>> between GMPLS border nodes. Further nesting can also occur within the
>> GMPLS network (see [LSP-HIER]).
>>
>> Full mesh of PSC FA-LSPs may be created between every border nodes
>> using a set of non-PSC FA-LSPs across the
>> GMPLS-based transit region [MAMLTE].
>> The merit of this mechanism is to attain the stability of MPLS-level
>> routing, i.e., the forwarding table of the LSR is kept intact even if
>> the topology composed of a set of non-PSC FA-LSPs are modified.
>> There is
>> not topology change from the view point of MPLS-level. Traffic
>> engineering is
>> performed by reconfiguring the virtual topology consisting of a set
>> of non-PSC FAs
>> across the GMPLS-based transit region.
>> Thanks to statistical multiplexing gain, there is no waste of
>> bandwidth resource even if a PSC FA-LSP is created.
>>
>>
>>
>>
>> .NH 3
>> Virtual FA
>> .XS
>> \*(SN Virtual FA
>> .XE
>>
>>
>> The virtual FA can be used instead of the FA to allow the path across
>> the
>> GMPLS-based transit region to be computed while avoiding waste of
>> bandwidth and adaptation
>> port occupation by non-PSC FA.
>>
>> A set of the virtual FAs forms the virtual topology for the
>> best-effort and/or the
>> traffic-engineered route across the GMPLS-based transit region. The
>> virtual topology
>> may be designed taking into account the (forecast) traffic demand and
>> available
>> resource in the GMPLS-based transit region. How to design the virtual
>> topology is out
>> of scope of this document.
>>
>> The virtual topology may dynamically change according to the change
>> of the (forecast)
>> traffic demand and the available resource in the transit region.
>> The virtual topology is changed by setting up and/or tearing down the
>> virtual FA.
>>
>>
>>
>>
>> .NH 2
>> LSP converting/LSP stitching
>> .XS
>> \*(SN LSP converting/LSP stitching
>> .XE
>>
>>
>> .NH 3
>> One-to-one relationship
>> .XS
>> \*(SN LSP One-to-one relationship
>> .XE
>>
>> LSP converting and LSP stitching have common property when they are
>> applied to the
>> reference model for MPLS-GMPLS-MPLS. There is a one-to-one relationship
>> between the e2e LSP and the transit segment. When the e2e LSP is set
>> up and/or torn down,
>> the associated transit segment is set up and/or torn down accordingly.
>>
>> Due to the one-to-one relationship, these mechanisms are relevant
>> only for MPLS - GMPLS (PSC) -MPLS scenario.
>>
>> .NH 3
>> Traffic demand change
>> .XS
>> \*(SN LSP Traffic demand change
>> .XE
>>
>> When the traffic demand for the e2e LSP changes, the bandwidth
>> allocated to the transit segment may be modified.
>> When the bandwidth is modified in the SENDER_TSPEC/FLOWSPEC object, the
>> LSP-ID field of SENDER_TEMPLATE object for the e2e LSP is modified in
>> both methods (make-before-break, see [RFC3209]).
>> This modification may trigger the same LSP ID change for the transit
>> segment if its bandwidth needs to be readjusted.
>>
>>
>>
>>
>>
>> .NH
>> Acknowledgements
>> .XS
>> \*(SN Acknowledgements
>> .XE
>>
>> The authors are grateful to Adrian Farrel for his numerous valuable
>> comments.
>>
>>
>> .NH
>> Security Considerations
>> .XS
>> \*(SN Security Considerations
>> .XE
>>
>> There are not security issues in this draft.
>>
>>
>>
>> .NH 1
>> References
>> .XS
>> \*(SN References
>> .XE
>>
>>
>>
>> .NH 2
>> Normative references
>> .XS
>> \*(SN Normative references
>> .XE
>>
>> [RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional
>> Description", RFC 3471, January 2003.
>>
>> [RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE
>> Extensions",
>> RFC 3473, January 2003.
>>
>> [GMPLS-ARCH] E. Mannie (Editor), "Generalized Multi-Protocol Label
>> Switching Architecture,"
>> <draft-ietf-ccamp-gmpls-architecture-07.txt> (Work in progress), May
>> 2003.
>>
>> [GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support
>> of Generalized MPLS",
>> <draft-ietf-ccamp-ospf-gmpls-extensions-12.txt> (work in progress),
>> October 2003.
>>
>> [GMPLS-ISIS]
>> "IS-IS extensions in support of generalized multi-protocol label
>> switching,"
>> <draft-ietf-isis-gmpls-extensions-19.txt> (work in progress), October
>> 2003.
>>
>>
>>
>> [GMPLS-LMP] J. Land, "Link management protocol (LMP),"
>> <draft-ietf-ccamp-lmp-10.txt> (work in progress), October 2003.
>>
>> [PWE3] S. Bryant, P. Pate (Editors), "PWE3 Architecture,"
>> <draft-ietf-pwe3-arch-07.txt> (work in progress), March 2003.
>>
>> [OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering
>> (TE)
>> Extensions to OSPF Version 2", RFC 3630, September 2003.
>>
>> [OSPF] J. Moy, "OSPF Version 2", RFC2328, April 1998.
>>
>>
>> .NH 2
>> Informative references
>> .XS
>> \*(SN Informative references
>> .XE
>>
>> [MRN] D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard. J.L.
>> Le Roux,
>> "Generalized MPLS Architecture for Multi-Region Networks,"
>> <draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt> (work in progress),
>> February 2004.
>>
>> [GMPLS-ROUTING] K. Kompella and Y. Rekhter, "Routing Extensions in
>> Support
>> of Generalized Multi-Protocol Label Switching,"
>> <draft-ietf-ccamp-gmpls-routing-09.txt> (work in progress), October
>> 2003.
>>
>> [Inter-domain] A. Farrel, J-P. Vasseur, and A. Ayyangar, "A framework
>> for inter-domain
>> MPLS traffic engineering,"
>> <draft-farrel-ccamp-inter-domain-framework-00.txt>
>> (work in progress), April 2004.
>>
>> [HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS
>> TE," <draft-ietf-mpls-lsp-hierarchy-08.txt> (work in progress),
>> September 2002.
>>
>> [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in
>> Resource
>> ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC3477,
>> January, 2003.
>>
>> [MAMLTE] K. Shiomoto et al.,
>> "Multi-area multi-layer traffic engineering using hierarchical LSPs
>> in GMPLS networks,"
>> <draft-shiomoto-multiarea-te-01.txt> (work in progress), June 2002.
>>
>> [P&R] J.P. Lang, Y. Rekhter, D. Papadimitriou (Editors), "RSVP-TE
>> Extensions in support of End-to-End GMPLS-based Recovery",
>> <draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01.txt> (work in
>> progress), May 2004.
>>
>>
>> [GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the
>> Overlay Model,"
>> <draft-ietf-ccamp-gmpls-overlay-04.txt> (work in progress), April 2004.
>>
>> [GMPLS-RECOVERY] CCAMP P&R Design Team, "Analysis of Generalized
>> Multi-Protocol Label
>> Switching (GMPLS)-based Recovery Mechanisms (including Protection and
>> Restoration),"
>> <draft-ietf-ccamp-gmpls-recovery-analysis-03.txt> (work in Progress),
>> April 2004.
>>
>> [TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions
>> for discovery of TE router information",
>> <draft-vasseur-ccamp-te-router-info-00.txt> (work in progress), July
>> 2004.
>>
>> [INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS
>> traffic engineering RSVP extensions",
>> <draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt> (work in
>> progress), July 2004.
>>
>> [MPLS-FRR] Ping Pan et. at., "Fast reroute extensions to RSVP-TE for
>> LSP tunnels," <draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. (work in
>> progress), May 2004.
>>
>> [GMPLS-SR] Louis Berger, Igor Bryskin, Dimitri Papadimitriou, Adrian
>> Farrel,
>> "GMPLS Based Segment
>> Recovery,"<draft-ietf-ccamp-gmpls-segment-recovery-00.txt> (work in
>> progress), March 2004.
>>
>> [INTER-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J.,
>> "Requirements for
>> Inter-Area MPLS Traffic Engineering",
>> <draft-ietf-tewg-interarea-mpls-te-req-02.txt>,
>> June 2004.
>>
>> .NH
>> Author's Address
>> .XS
>> \*(SN Author's Address
>> .XE
>>
>> .nf
>> Deborah Brungard
>> AT&T
>> Rm. D1-3C22 - 200 S. Laurel Ave.
>> Middletown, NJ 07748, USA
>> Phone: +1 732 420 1573
>> E-mail: dbrungard@att.com
>>
>> Jean-Louis Le Roux
>> France Telecom R&D
>> av Pierre Marzin
>> 22300 Lannion
>> France
>> E-mail: jeanlouis.leroux@francetelecom.com
>>
>> .nf
>> Eiji Oki
>> NTT
>> Midori 3-9-11
>> Musashino, Tokyo 180-8585, Japan
>> E-mail: oki.eiji@lab.ntt.co.jp
>>
>> Dimitri Papadimitriou
>> Alcatel
>> Francis Wellensplein 1,
>> B-2018 Antwerpen, Belgium
>> Phone : +32 3 240 8491
>> E-mail: dimitri.papadimitriou@alcatel.be
>>
>> Daisaku Shimazaki
>> NTT
>> Midori 3-9-11
>> Musashino, Tokyo 180-8585, Japan
>> E-mail: shimazaki.daisaku@lab.ntt.co.jp
>>
>> Kohei Shiomoto
>> NTT
>> 3-9-11 Midori-cho,
>> Musashino-shi, Tokyo 180-8585, Japan
>> E-mail: shiomoto.kohei@lab.ntt.co.jp
>>
>>
>>
>>
>> .NH
>> Intellectual Property Rights Notices
>> .XS
>> \*(SN Intellectual Property Rights Notices
>> .XE
>>
>> The IETF takes no position regarding the validity or scope of any
>> intellectual property
>> 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; neither does it represent
>> that it has made any
>> effort to identify any such rights. Information on the IETF's
>> procedures with respect
>> to rights in standards-track and standards-related documentation can
>> be found in
>> BCP-11. Copies of claims of rights made available for publication
>> 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 implementors
>> or users of this specification can be obtained from the IETF
>> Secretariat.
>>
>> The IETF invites any interested party to bring to its attention any
>> copyrights, patents
>> or patent applications, or other proprietary rights which may cover
>> technology that
>> may be required to practice this standard. Please address the
>> information to the
>> IETF Executive Director.
>>
>> .NH 2
>> IPR Disclosure Acknowledgement
>> .XS
>> \*(SN IPR Disclosure Acknowledgement
>> .XE
>>
>> By submitting this Internet-Draft, I certify that any applicable patent
>> or other IPR claims of which I am aware have been disclosed, and any of
>> which I become aware will be disclosed, in accordance with RFC 3668.
>>
>> .SH
>> Full Copyright Statement
>> .XS
>> Full Copyright Statement
>> .XE
>>
>> Copyright (C) The Internet Society (2003). All Rights Reserved.
>>
>> This document and translations of it may be copied and furnished to
>> others, and
>> derivative works that comment on or otherwise explain it or assist in
>> its
>> implementation may be prepared, copied, published and distributed, in
>> whole or in
>> part, without restriction of any kind, provided that the above
>> copyright notice and this
>> paragraph are included on all such copies and derivative works.
>> However, this
>> document itself may not be modified in any way, such as by removing
>> the copyright
>> notice or references to the Internet Society or other Internet
>> organizations, except as
>> needed for the purpose of developing Internet standards in which case
>> the procedures
>> for copyrights defined in the Internet Standards process must be
>> followed, or as
>> required to translate it into languages other than English.
>>
>> The limited permissions granted above are perpetual and will not be
>> revoked by the
>> Internet Society or its successors or assignees.
>>
>> This document and the information contained herein is provided on an
>> "AS IS" basis
>> and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
>> FORCE DISCLAIMS 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.
>>
>>
>>
>>
>>
>> .TC
>
</x-flowed>
CCAMP Working Group Deborah Brungard (AT&T)
Internet Draft Jean-Louis Le Roux (France Telecom)
Expiration Date: December 2004 Eiji Oki (NTT)
Dimitri Papadimitriou (Alcatel)
Daisaku Shimazaki (NTT)
Kohei Shiomoto (NTT)
July 2004
Migrating from IP/MPLS to GMPLS networks
draft-oki-ccamp-gmpls-ip-interworking-03.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
[Page 1]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
Abstract
This document is addressing the migration from Multi-protocol label
switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to
expand the capacity of the existing MPLS-based infrastructure network,
the optical network consisting of L2SC, TDM, LSC, and FSC devices will
be deployed, which is controlled by the GMPLS protocols. GMPLS protocols
are, however, subtly different from MPLS protocols. In this document we
describe possible migration scenarii, the mechanisms to compensate the
difference between MPLS and GMPLS protocols, and how the mechanisms are
applied to migrate from the MPLS to the GMPLS network.
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.
1. Introduction
Multi-protocol label switching (MPLS) is widely deployed with applica-
tions such as traffic engineering and virtual private network (VPN).
Various kinds of services such as VoIP, IPv6, L2VPN/L3VPN, pseudo wire
emulation are expected to be converged over the MPLS-based infrastruc-
ture network.
Traffic volume is tremendously increasing as broadband service enabled
by ADSL and FTTH is rapidly penetrating the market and the processing
performance of terminal and server is ever increasing. In order to cope
with such increase of the traffic volume, optical networks, which con-
sists of L2SC, TDM, LSC, and FSC devices, will be introduced.
Generalized MPLS (GMPLS) is being standardized by extending MPLS to con-
trol such optical networks (see [RFC3471], [RFC3473], [GMPLS-ROUTING],
[GMPLS-OSPF], [GMPLS-ISIS], [GMPLS-LMP]). GMPLS network will be deployed
as a part of the existing MPLS infractructure. MPLS and GMPLS devices
will coexist in the network until the existing MPLS network is com-
pletely migrated to the GMPLS network.
GMPLS protocols are, however, subtly extending MPLS protocols' capabili-
ties. In order to migrate from the existing MPLS to the GMPLS network,
we need to define mechanisms to compensate the difference between MPLS
[Page 2]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
and GMPLS. In this document we discuss the migration scenarii from MPLS
to GMPLS networks, the mechanisms to compensate the difference between
MPLS and GMPLS, and the applicability of the mechanisms to the possible
migration scenarii.
We should note that GMPLS covers Packet Switching Capable (PSC) networks
[GMPLS-ARCH]. In the rest of this document, when dealing with GMPLS, it
means both PSC and non-PSC. Otherwise PSC GMPLS or non-PSC GMPLS is
explicitly mentioned.
GMPLS introduces new features such as bidirectional LSPs, label sugges-
tion, label restriction, graceful restart, graceful teardown, and for-
warding adjacencies (see [GMPLS-ARCH]). Also several features are pro-
vided in a distinct manner. For instance local protection is provided
using distinct mechanisms in MPLS (see [MPLS-FRR]) and GMPLS (see
[GMPLS-SR]). Migration from MPLS to GMPLS should bring these features
and such distinct mechanisms in the existing MPLS-based infrastructure
network.
The rest of this document is organized as follows. In Section 2, we
taxonomize the migration scenarii from MPLS to GMPLS networks. In Sec-
tion 3, we describe the problems caused by the difference between MPLS
and GMPLS protocols. In Section 4, we present the required mechanisms,
which bridge the difference between MPLS and GMPLS protocols. Some of
those mechanisms are available today and others are not. In Section 5,
we present the applicability of the required mechanisms to a reference
network model for the migration from MPLS to GMPLS networks.
2. Migration scenarii
Two categories of migration scenarii are considered: (1) MPLS-GMPLS-MPLS
and (2) GMPLS-MPLS-GMPLS. In case of (1) MPLS-GMPLS-MPLS scenario,
source and destination nodes of the Label Switched path (LSP) are in
MPLS and a set of its intermediate nodes take part of GMPLS. In case of
(2) GMPLS-MPLS-GMPLS scenario, LSP source and destination nodes are in
GMPLS network and a set of its intermediate nodes take part of MPLS net-
work. Each category is subdivided in two sub-categories as to whether
GMPLS is PSC or non-PSC.
MPLS-GMPLS (PSC) migration scenario, where LSP start/end in an MPLS net-
work and end/start in a GMPLS PSC network, will be addressed in a future
revision.
[Page 3]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
2.1. MPLS-GMPLS(non-PSC)-MPLS
Introduction of a GMPLS-based optical core network to increase the
capacity is an example of this category. TDM, LSC, and/or FSC LSPs are
established between MPLS networks across the GMPLS network. A set of
those LSPs provide virtual network topology for MPLS networks. This
topology may be reconfigurable by adding and/or removing those LSPs
[MRN]. MPLS LSRs and subnetworks interconnected at the edges of the vir-
tual network topology may form a single MPLS network.
Figure 1 shows the reference network model for the MPLS-GMPLS(non-
PSC)-MPLS migration. The reference network model consists of three
regions: ingress, transit, and egress. Both the ingress and egress
regions are MPLS-based while the transit region is GMPLS-based. The
nodes at the boundary of the MPLS and GMPLS regions (G1, G2, G5, and G6)
are referred to as "border node" hereafter. All nodes except the border
nodes in the GMPLS-based transit region (G3 and G4) are non-PSC device,
i.e., optical equipment (TDM, LSC, and FSC). An MPLS LSP can be provi-
sioned from a node in the ingress MPLS-based region (say, R2) to a node
in the egress MPLS-based region (say, R4). The LSP is referred to as
the "e2e" LSP hereafter. The switching capability of both end points of
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 1 MPLS-GMPLS(non-PSC)-MPLS migration model.
[Page 4]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
2.2. MPLS-GMPLS(PSC)-MPLS
MPLS-based converged network can be migrated to GMPLS (PSC)-based con-
verged network. The rationale of this type of migration scenario is
supported by two factors: (1) GMPLS-based advanced feature, (2) stepwise
migration for the GMPLS-based optical core network. Regarding the
GMPLS-based advanced feature, numerous features are being developed in
GMPLS context (and MPLS) including bi-directional LSP, label control,
graceful restart, graceful teardown and forwarding adjacencies. Exist-
ing MPLS-based converged network could be migrated to GMPLS (PSC)-based
converged network to deliver the advanced features. Once the PSC network
is migrated to GMPLS-based one, it could be migrated to GMPLS-based
optical core network with less effort.
2.3. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC)
In this scenario, TDM, L2SC e2e LSPs are provisioned in the GMPLS net-
work, which is partly disconnected. In case the MPLS-based infrastruc-
ture network is widely deployed, it is used to bridge the disconnected
GMPLS networks. Moreover, pseudo wire emulation is used edge-to-edge in
the MPLS-based converged network to carry those LSPs [PWE3].
Figure 2 shows the reference network model for the GMPLS(non-PSC)-MPLS-
GMPLS(non-PSC) migration. The reference network model consists of three
regions: ingress, transit, and egress. Both the ingress and egress
regions are GMPLS-based while the transit region is MPLS-based. The
nodes at the boundary of the MPLS and GMPLS regions (G3, G4, G5, and G6)
are referred to as "border node" hereafter. All nodes except the border
nodes in the GMPLS-based regions (G1, G11, G2, G21, G71, G7, G81, and
G8) are non-PSC devices. A GMPLS LSP can be provisioned from a node in
the ingress GMPLS-based region (say, G2) to a node in the egress GMPLS-
based region (say, G8). The LSP is referred to as the "e2e" LSP here-
after. The switching capability of both end points of e2e LSP must be
the same.
[Page 5]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
.................. ............................. ..................
: GMPLS(non-PSC) : : MPLS : : GMPLS(non-PSC) :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|G1 |__|G11|___|G3 |__________|R1 |__________|G5 |___|G71|__|G7 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|G2 |__|G21|___|G4 |__________|R2 |__________|G6 |___|G81|__|G8 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<-------------------------------------------------------->|
e2e LSP
Figure 2 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration model.
2.4. GMPLS(PSC)-MPLS-GMPLS(PSC)
In this scenario, GMPLS PSC e2e LSPs are provisioned in the GMPLS net-
work, which is partly disconnected. In case the MPLS-based infrastruc-
ture network is widely deployed, it is used to bridge the disconnected
GMPLS networks. Since MPLS-based network is PSC, the GMPLS PSC LSP can
cross MPLS-based converged network without extra treatment in data
plane.
3. Difference between MPLS and GMPLS protocols
3.1. Routing
In this document we assume that the OSPF-TE is used as IGP-TE. However
the IGP-TE description should apply to both IS-IS and OSPF. Specifics
concerning IS-IS will be detailed in the next release of this document.
TE-link information is advertised in link state advertisement. It
allows collecting the whole topology information, which is stored in
traffic-engineering data base (TEDB). Best-effort route and/or traffic-
engineered explicit route for the destination are calculated using the
TEDB.
[Page 6]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
GMPLS extends the set of sub-TLVs for TE-link advertisements. Non-PSC
TE-link information used in GMPLS is not supported by MPLS. Even PSC TE-
link information used in GMPLS is not fully supported by MPLS (this is
particularly the case for the Interface Switching Capability Descriptor
sub-TLV). As a result, one cannot compute traffic-engineered explicit
route if they are travelling through both MPLS and GMPLS regions.
Figure 3 illustrates the problem of mismatch of TE-link information in
MPLS and GMPLS. Suppose that an e2e LSP is provisioned between R2 and
R4 and that we need to compute the path between R2 and R4 (say,
R2-R21-G2-G4-G6-R41-R4). The TE link information for the links R2-R21,
R21-G2, G6-R41 and R41-R4 is MPLS-based TE link LSA, while the ones for
the links G2-G4 and G4-G6 is GMPLS-based. The node in MPLS-based
ingress region (say, R2) cannot compute the path, which consists of mix-
ture of MPLS-based and GMPLS-based TE link 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 3 Problem mismatch of TE-link information in MPLS and GMPLS
Except for Opaque-LSA associated with TE-link, MPLS and GMPLS use the
same set of LSAs, e.g., router-LSA, network-LSA, summary-LSA and etc.
These LSAs in GMPLS network construct the topology database of the con-
trol plane of GMPLS network.
3.2. Signaling
GMPLS RSVP-TE signalling ([RFC 3473]) introduces new objects, and their
associated procedures, that can not be processed/inserted by MPLS LSRs:
[Page 7]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
- The (Generalized) Label Request object (new C-Type), used to iden-
tify the LSP encoding type, the switching type and the generalized
protocol ID (G-PID) associated with the LSP.
- The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID
ERO/RRO subobjects that handle the Control plane/Data plane separa-
tion in GMPLS network.
- The Suggested Label Object, used to reduce LSP setup delays.
- The Label Set Object, used to restrict label allocation to a set of
label, which (particularly useful for wavelength conversion inca-
pable nodes)
- The Upstream Label Object, used for bidirectional LSP setup (see
also 3.4)
- The Restart Cap object, used for graceful restart.
- The Admin Status object, used for LSP administration, and particu-
larly for graceful LSP teardown.
3.3. Control plane/data plane separation
TDM, LSC, FSC networks do not recognize packet delineation. In GMPLS,
the control channel can be logically (in-band) or physically (out-of-
band) separated from the data channel in those networks. The control
channels between adjacent nodes constitute a control plane network. Con-
trol packets of routing and signaling protocols are transmitted over the
control plane network.
If the GMPLS network consists of only PSC devices, there can be no con-
trol plane/data plane separation. All control packets share the same
network links with data packets. If the GMPLS network consists of non-
PSC devices, there is at least a logical C/D separation at least between
PSC device and non-PSC device in GMPLS networks and between non-PSC and
non-PSC devices.
The GMPLS control plane, which is designed to carry the control packet
in GMPLS network, is not likely to have enough capacity to carry the
user-data traffic from MPLS network. Therefore, the control plane must
ensure is it not carrying data traffic from the MPLS network (see
[GMPLS-ROUTING]).
[Page 8]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
3.4. Bi-directional LSP
Since GMPLS supports TDM, LSC, and FSC switching and LSP classes, which
are mainly bi-directional channels, it also provides bi-directional LSP
setup. In a single signaling session, bi-directional LSPs can be created
along the same route in GMPLS network. On the other hand, there is no
equivalent mechanism to support bi-directional LSPs in MPLS network. The
forward and backward LSPs are created in different signaling sessions.
The route taken by those LSPs may be different from each other. Their
sessions are treated differently from each other.
If MPLS and GMPLS networks are inter-connected, the bi-directional LSPs
from GMPLS network need to be carried in MPLS network, which does not
support bi-directional LSP setup. At least we need a mechanism allowing
to route the forward and backward LSPs on the same route.
4. Required mechanism
In this section, we present at set of routing and signalling mechanisms,
in order to bridge the difference between MPLS and GMPLS protocols.
This section only proposes mechanisms for MPLS-GMPLS-MPLS migration.
GMPLS-MPLS-GMPLS (using PWE3 stuff) is for further study.
4.1. Routing
The entire network consisiting of ingress, transit, and egress regions
(See Fig.1 or 2 for instance) may be either single-area or multi-area
from the IGP perspective.
4.1.1. Single-area
If the entire network is a single-area, the partial topology of GMPLS-
based region, which is consisting of PSC-link, should be visible to MPLS
regions. GMPLS TE-links are advertised as MPLS TE-links using MPLS-
based TE link information to the MPLS networks so that node in the MPLS
region can understand the GMPLS TE-links. This requires some TE-link
[Page 9]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
information conversion.
If the GMPLS-based region consists of only non-PSC devices except the
border nodes, PSC-links should be set up between the border nodes. For
example, in Fig. 3, a PSC-link can be set up between G2 and G6. PSC-
links are advertised as the forwarding adjacency (FA) in the GMPLS-
based region. The e2e LSP can be tunnelled through the FA [HIER]. In
the MPLS to GMPLS migration scenarii, FA should be advertised as TE-
links in the MPLS regions, using MPLS-based TE-link information.
A set of FAs across the GMPLS region provides the virtual network topol-
ogy (VNT), which can be reconfigured by creating and/or destroying FAs,
to MPLS regions. See [MRN] for details.
MPLS TE-links MAY be understood by the nodes in the GMPLS network, which
can transform MPLS-based TE-link information into GMPLS-based TE-link
information.
4.1.1.1. Virtual FA
If the entire network consists of a single IGP area and the GMPLS-based
region consists of only non-PSC devices except the border nodes, FAs
should be set up between the GMPLS border nodes. To avoid unnecessary
bandwidth consumption non-PSC FA LSP should be created only if there
exists traffic demand between the end points.
In order to compute the path across the GMPLS region, the FA-LSP must be
set up for being advertized as per [HIER]. The "virtual" FA-LSP is
defined here to cope with the situation. The virtual FA-LSP is not
instantiated but is advertised as a TE-link by routing protocol to
attract traffic. The virtual FA may be provisioned using the similar
method for provisioning the secondary LSP in the shared mesh restoration
scheme [P&R]. Or the virtual FA may be just signalled between both end
points without having the transit nodes intervene.
A set of virtual FAs forms the virtual topology for the best-effort
and/or the traffic-engineered route across the GMPLS region. The virtual
topology may be designed taking into account the (forecast) traffic
demand and the available resource in the transit region. The virtual
topology may dynamically change according to the variation of the (fore-
cast) traffic demand and the available resource in the transit region to
optimize the tradeoff between network performance and the residual net-
work capacity. How to design the virtual topology and its changes is out
of scope of this document.
The virtual topology is changed by setting up and/or tearing down
[Page 10]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
virtual FA-LSP. Signaling messages are used to exchange the link iden-
tifiers in a similar way of the FA as described in [RFC3477] and [LSP-
HIER]. Unlike the case of FA-LSP, the intermediate nodes may not be
involved in signaling message processing when the virtual FA-LSP is not
provisioned (Just link interface identifiers are exchanged by signaling
between ingress and egress nodes). Both unnumbered and numbered virtual
FAs should be defined.
There is no routing adjacency along the (virtual) FA. There is no hello
packets exchanged between the end points of the (virtual) FA.
When an e2e MPLS LSP is setup through a virtual FA, this should trigger
the setup of a real FA-LSP is the GMPLS network.
4.1.2. Multi-area
A simple migration approach can also consist in separating MPLS and
GMPLS networks into distinct IGP areas, and then rely on multi-area
routing, path computation, and signaling solutions under specification
in CCAMP WG (ABR acting as a Path Computation Element for instance).
Basicaly there is no backward compatibility issue when MPLS and GMPLS
LSRs resides in disctinct IGP areas, as TE-link information is not
leaked across area (see see [INTER-AREA-REQ] and [INTER-Domain]).
4.2. Signaling
We describe the signaling mechanisms, which can be applied to the migra-
tion scenarii from MPLS to GMPLS. Three basic cases for the MPLS-GMPLS-
MPLS environment are described in Fig. 4: LSP nesting, LSP converting,
and LSP stitching.
LSP nesting: One or more packet LSPs is nested into one LSP.
LSP converting: The end-to-end packet LSP signaling messages (RFC 3209)
is translated at the GMPLS borders into GMPLS RSVP-TE (see RFC 3473).
The GMPLS RSVP-TE segment MUST also be PSC. This case requires a ser-
vice interworking function 3209/3473 (at the control plane level).
LSP stitching: A segment PSC LSP is stitched within an end-to-end packet
LSP. This case does require a network interworking function (at the
control plane level) since MPLS signaling messages are directed between
GMPLS border nodes.
[Page 11]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
................. .............................. ..................
: MPLS : : GMPLS (PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
session for e2e LSPs
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
session for FA/LSP tunnel
|<-------------------------->|
e2e LSP _____________________________
<------------ | FA/LSP tunnel | ----------->
<------------ | | ----------->
<------------ | | ----------->
|_____________________________|
(a) LSP nesting
e2e session
|<-------------------------------------------------------->|
____________ ____________________________ ____________
| MPLS seg. || GMPLS segment || MPLS seg. |
|____________||____________________________||____________|
(b) LSP converting
e2e session
|<-------------------------------------------------------->|
transit session
|<-------------------------->|
____________ ____________________________ ____________
| MPLS seg. || GMPLS segment || MPLS seg. |
|____________||____________________________||____________|
(c) LSP stitching
Figure 4 Comparisons of signaling in MPLS-GMPLS-MPLS migration model.
[Page 12]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
4.2.1. LSP nesting
Figure 4 (a) illustrates the LSP nesting in the MPLS-GMPLS-MPLS refer-
ence network model. An FA-LSP is created by setting up the FA-LSP. FA
is established between the boundary of the ingress and the transit
regions and that of the transit and the egress regions. Three e2e LSPs
are provisioned between the nodes in the MPLS-based ingress region (say,
R2) and egress region (say, R4). These e2e LSPs are tunnelled inside
the same FA-LSP across the transit region.
LSP nesting is different from the LSP stitching and the LSP converting
with respect to data plane. The e2e LSP is nested inside the FA while
there is no nesting in the LSP stitching and the LSP converting. Multi-
ple e2e LSPs can be nested inside a single FA-LSP. Scalability is
hereby attained.
There exist at least two sessions: one for the FA-LSP and the others for
e2e LSP(s). Along the FA-LSP, the state is created and maintained dur-
ing the life-time of the FA-LSP. When the FA-LSP is re-routed (for
example due to re-optimization, failure recovery, etc.), the FA link is
not impacted as long as the alternative FA-LSP exists.
FA-LSP mechanism applies to MPLS-GMPLS (non PSC)-MPLS and MPLS-GMPLS
(PSC)-MPLS migration scenarii.
4.2.2. LSP converting
LSP can be converted from MPLS to GMPLS and vice versa at the boundary
of MPLS and GMPLS regions while remaining in the same session. This is
achieved by delivering an interworking function at the control plane of
the GMPLS border nodes. Figure 4 (b) illustrates the LSP converting in
the MPLS-GMPLS-MPLS reference network model. The e2e LSP is provisioned
between the nodes in the MPLS-based ingress region (say, R2) and egress
region (say, R4). The e2e LSP consists of three segments: ingress,
transit, egress. The transit segment is GMPLS-based and therefore it is
referred to as GMPLS-segment while others are referred to as MPLS-seg-
ments. The e2e LSP is associated with the single session, which is
referred to as the "e2e" session. This is relevant only for MPLS-GMPLS
(PSC)-MPLS migration scenario.
4.2.2.1. MPLS->GMPLS
LSP is converted from MPLS to GMPLS at the boundary of MPLS ingress and
GMPLS transit regions. In case of C/D separation in the GMPLS transit
[Page 13]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
region, the signaling message is separated from the data plane network
at the boundary.
Regarding the control plane, the signaling message associated with the
e2e LSP is carried in the control plane network in the GMPLS transit
region. Appropriate objects newly defined for GMPLS (say, Generalized
label request object) is attached to the signaling message.
4.2.2.2. GMPLS->MPLS
LSP is converted from GMPLS to MPLS at the boundary of GMPLS transit and
MPLS egress regions. In case of C/D separation in the GMPLS transit
region, the signaling message from the data plane network is multiplexed
to the data plane message at the boundary. LSP is converted with
respect to both the control and the data plane aspects.
Regarding the control plane aspect, the signaling message objects, which
are not supported by MPLS, are lost. The associated functions are not,
therefore, effective in MPLS network accordingly. GMPLS-segment is
either uni-directional or bi-directional. There is no mechanism to set
up the bi-directional MPLS LSPs within the same session along the same
route.
4.2.2.3. ERO/RRO processing
There are three cases depending on the level of detail of the transit
segment specified as part of the EROs issued in the Path message issued
by the ingress of the e2e LSP.
1) The ERO issued by the ingress of the e2e LSP includes the tail-end
of the transit segment as a strict subobject. Then, if the head-
end of the transit segment is also included as a strict node, in
this case ERO processing follows rules described in Section 8.2 of
[LSP-HIER] as the sequence of the transit segment is complete once
issued by the ingress of the e2e LSP. Otherwise, if the head-end
node of the transit segment (or any other subobject preceding the
tail-end) is specified as a loose subobject, the preceding strict
node inserts the sequence of subobjects within the ERO as specified
in [RFC 3209] to reach the next loose node.
[Page 14]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
2) The ERO issued by the ingress of the e2e LSP includes both head-
(strict or loose) and tail-end (loose) of the transit segment. In
this case, the ingress GMPLS border node inserts sequence of subob-
jects within the ERO as specified in [RFC 3209] to reach the egress
border node.
3) The ERO issued by the ingress of the e2e LSP does not include the
tail-end of the transit segment. In this case, the ingress border
node should decide the exit point to reach the next loose node
being outside of the transit region.
RROs in the transit segment may carry the nodes in the transit region.
The nodes in the transit segment may be removed from the RROs when they
depart from the transit region. The ingress and egress border nodes
should be included in the RROs when they are carried in the ingress and
the egress regions.
4.2.3. LSP stitching
LSP can be stitched at the boundary of MPLS and GMPLS regions [Inter-
domain]. The LSP stretches from the ingress through the transit to the
egress regions. Figure 4 (c) illustrates the LSP stitching in the MPLS-
GMPLS-MPLS reference network model. The e2e LSP is provisioned between
the nodes in the MPLS-based ingress region (say, R2) and egress region
(say, R4). The e2e LSP consists of two segments: ingress/egress and
transit. The transit segment is GMPLS-based and therefore it is
referred to as GMPLS-segment while others are referred to as MPLS-seg-
ments. The e2e LSP is associated with the two sessions: one for the
entire stretch (i.e., ingress to egress regions) and the other for the
transit segment. The signaling mechanisms described in [INTER-DOMAIN-
SIG] can be applied.
4.2.4. Discovery of GMPLS signalling capability
I may be useful to advertise into the IGP the capability of a node to
support GMPLS signalling. This would allow every node in the network to
automatically discover the GMPLS signalling regions. [TE-INFO] provides
a functional description of routing extensions in order to advertise TE
router information, including Control Plane Capabilities such as GMPLS
signaling.
[Page 15]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
5. MPLS-GMPLS-MPLS reference model
In this section, the required mechanisms with the MPLS-GMPLS-MPLS refer-
ence network model is discussed. FA/LSP tunnel, LSP converting, and LSP
stiching are applied to the reference network model.
>From Figure 1, we consider that the packet LSP is set up between the
ingress and the egress regions. The LSP is referred to as "e2e" LSP
hereafter. The LSP portion corresponding to the transit GMPLS-base
region is referred to as "transit segment". The transit segment is
implemented by either (1) LSP nesting, (2) LSP converting, or (3) LSP
stitching.
5.1. LSP nesting
5.1.1. Basic description
FAs are created between the GMPLS border nodes. The FAs are advertised
in the MPLS regions, by the routing protocol, using MPLS TE-link infor-
mation ([OSPF-TE] or [ISIS-TE]).
The e2e LSP is tunneled through the FA across the GMPLS-based transit
region. Multiple e2e LSPs may be tunnelled through a single FA. The e2e
LSP may be carried over multiple hops of FAs across the GMPLS-based
transit region unless there is no direct FA between the ingress and the
egress regions.
5.1.2. Traffic demand change
Traffic demand may change after the FA is created. Some FAs, which do
not carry any e2e LSP any longer may be released for resource release.
They may be also retained for future usage. Release or retention of
underutilized FAs is a policy decision. Detail of the policy is out of
scope of this document.
FAs may be created based on the policy, which might consider residual
resource in GMPLS-based transit region and the change of traffic demand.
By creating the new FAs, the network performance such as maximum resid-
ual capacity may be improved.
As the number of FAs grows, the residual resource in the GMPLS-based
transit region may decrease. In this case, re-optimization may be
invoked in the GMPLS-based transit region according the the policy.
[Page 16]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
Detail of the policy is again out of scope of this document.
As part of the reoptimization process, FA-LSPs may be rerouted while
keeping interface identifiers of FA links unchanged. However, the rout-
ing in MPLS level should be unaffected since there is no change of
topology composed of FAs across the GMPLS-based transit region.
When residual resource in the GMPLS-based transit region decreases, some
FAs may be released according to the policy. Detail of the policy is
again out of scope of this document. The FA should be released only
after the LSA associated with the FA is deleted throughout the network.
Once the LSA is deleted, the e2e LSPs routed over the FA are expected to
get rerouted around the FA.
5.1.3. Nest of FAs
E2e LSP can be tunneled into the PSC or non-PSC FA LSPs established
between GMPLS border nodes. Further nesting can also occur within the
GMPLS network (see [LSP-HIER]).
Full mesh of PSC FA-LSPs may be created between every border nodes using
a set of non-PSC FA-LSPs across the GMPLS-based transit region [MAMLTE].
The merit of this mechanism is to attain the stability of MPLS-level
routing, i.e., the forwarding table of the LSR is kept intact even if
the topology composed of a set of non-PSC FA-LSPs are modified. There
is not topology change from the view point of MPLS-level. Traffic engi-
neering is performed by reconfiguring the virtual topology consisting of
a set of non-PSC FAs across the GMPLS-based transit region. Thanks to
statistical multiplexing gain, there is no waste of bandwidth resource
even if a PSC FA-LSP is created.
5.1.4. Virtual FA
The virtual FA can be used instead of the FA to allow the path across
the GMPLS-based transit region to be computed while avoiding waste of
bandwidth and adaptation port occupation by non-PSC FA.
A set of the virtual FAs forms the virtual topology for the best-effort
and/or the traffic-engineered route across the GMPLS-based transit
region. The virtual topology may be designed taking into account the
(forecast) traffic demand and available resource in the GMPLS-based
transit region. How to design the virtual topology is out of scope of
[Page 17]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
this document.
The virtual topology may dynamically change according to the change of
the (forecast) traffic demand and the available resource in the transit
region. The virtual topology is changed by setting up and/or tearing
down the virtual FA.
5.2. LSP converting/LSP stitching
5.2.1. One-to-one relationship
LSP converting and LSP stitching have common property when they are
applied to the reference model for MPLS-GMPLS-MPLS. There is a one-to-
one relationship between the e2e LSP and the transit segment. When the
e2e LSP is set up and/or torn down, the associated transit segment is
set up and/or torn down accordingly.
Due to the one-to-one relationship, these mechanisms are relevant only
for MPLS - GMPLS (PSC) -MPLS scenario.
5.2.2. Traffic demand change
When the traffic demand for the e2e LSP changes, the bandwidth allocated
to the transit segment may be modified. When the bandwidth is modified
in the SENDER_TSPEC/FLOWSPEC object, the LSP-ID field of SENDER_TEMPLATE
object for the e2e LSP is modified in both methods (make-before-break,
see [RFC3209]). This modification may trigger the same LSP ID change
for the transit segment if its bandwidth needs to be readjusted.
6. Acknowledgements
The authors are grateful to Adrian Farrel for his numerous valuable com-
ments.
[Page 18]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
7. Security Considerations
There are not security issues in this draft.
8. References
8.1. Normative references
[RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional
Description", RFC 3471, January 2003.
[RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE Exten-
sions", RFC 3473, January 2003.
[GMPLS-ARCH] E. Mannie (Editor), "Generalized Multi-Protocol Label
Switching Architecture," <draft-ietf-ccamp-gmpls-architecture-07.txt>
(Work in progress), May 2003.
[GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS", <draft-ietf-ccamp-ospf-gmpls-extensions-12.txt> (work
in progress), October 2003.
[GMPLS-ISIS] "IS-IS extensions in support of generalized multi-protocol
label switching," <draft-ietf-isis-gmpls-extensions-19.txt> (work in
progress), October 2003.
[GMPLS-LMP] J. Land, "Link management protocol (LMP)," <draft-ietf-
ccamp-lmp-10.txt> (work in progress), October 2003.
[PWE3] S. Bryant, P. Pate (Editors), "PWE3 Architecture," <draft-ietf-
pwe3-arch-07.txt> (work in progress), March 2003.
[OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF] J. Moy, "OSPF Version 2", RFC2328, April 1998.
[Page 19]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
8.2. Informative references
[MRN] D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard. J.L. Le
Roux, "Generalized MPLS Architecture for Multi-Region Networks," <draft-
vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt> (work in progress), February
2004.
[GMPLS-ROUTING] K. Kompella and Y. Rekhter, "Routing Extensions in Sup-
port of Generalized Multi-Protocol Label Switching," <draft-ietf-ccamp-
gmpls-routing-09.txt> (work in progress), October 2003.
[Inter-domain] A. Farrel, J-P. Vasseur, and A. Ayyangar, "A framework
for inter-domain MPLS traffic engineering," <draft-farrel-ccamp-inter-
domain-framework-00.txt>
(work in progress), April 2004.
[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS
TE," <draft-ietf-mpls-lsp-hierarchy-08.txt> (work in progress), Septem-
ber 2002.
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC3477,
January, 2003.
[MAMLTE] K. Shiomoto et al., "Multi-area multi-layer traffic engineering
using hierarchical LSPs in GMPLS networks," <draft-shiomoto-multiarea-
te-01.txt> (work in progress), June 2002.
[P&R] J.P. Lang, Y. Rekhter, D. Papadimitriou (Editors), "RSVP-TE
Extensions in support of End-to-End GMPLS-based Recovery", <draft-ietf-
ccamp-gmpls-recovery-e2e-signaling-01.txt> (work in progress), May 2004.
[GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the Overlay
Model," <draft-ietf-ccamp-gmpls-overlay-04.txt> (work in progress),
April 2004.
[GMPLS-RECOVERY] CCAMP P&R Design Team, "Analysis of Generalized Multi-
Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including
Protection and Restoration)," <draft-ietf-ccamp-gmpls-recovery-analy-
sis-03.txt> (work in Progress), April 2004.
[TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions for
discovery of TE router information", <draft-vasseur-ccamp-te-router-
info-00.txt> (work in progress), July 2004.
[INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS traffic
engineering RSVP extensions", <draft-ayyangar-ccamp-inter-domain-rsvp-
[Page 20]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
te-00.txt> (work in progress), July 2004.
[MPLS-FRR] Ping Pan et. at., "Fast reroute extensions to RSVP-TE for LSP
tunnels," <draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt. (work in
progress), May 2004.
[GMPLS-SR] Louis Berger, Igor Bryskin, Dimitri Papadimitriou, Adrian
Farrel, "GMPLS Based Segment Recovery,"<draft-ietf-ccamp-gmpls-segment-
recovery-00.txt> (work in progress), March 2004.
[INTER-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements
for Inter-Area MPLS Traffic Engineering", <draft-ietf-tewg-interarea-
mpls-te-req-02.txt>, June 2004.
9. Author's Address
Deborah Brungard
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 420 1573
E-mail: dbrungard@att.com
Jean-Louis Le Roux
France Telecom R&D
av Pierre Marzin
22300 Lannion
France
E-mail: jeanlouis.leroux@francetelecom.com
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
E-mail: oki.eiji@lab.ntt.co.jp
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
E-mail: dimitri.papadimitriou@alcatel.be
Daisaku Shimazaki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
[Page 21]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
E-mail: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
E-mail: shiomoto.kohei@lab.ntt.co.jp
10. Intellectual Property Rights Notices
The IETF takes no position regarding the validity or scope of any intel-
lectual property 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; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made available for
publication 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 implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this stan-
dard. Please address the information to the IETF Executive Director.
10.1. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
[Page 22]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or ref-
erences to the Internet Society or other Internet organizations, except
as needed for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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 FIT-
NESS FOR A PARTICULAR PURPOSE.
[Page 23]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Conventions used in this document . . . . . . . . . . . . . . . . . 2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Migration scenarii . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. MPLS-GMPLS(non-PSC)-MPLS . . . . . . . . . . . . . . . . . . . 4
2.2. MPLS-GMPLS(PSC)-MPLS . . . . . . . . . . . . . . . . . . . . . 5
2.3. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) . . . . . . . . . . . . . . 5
2.4. GMPLS(PSC)-MPLS-GMPLS(PSC) . . . . . . . . . . . . . . . . . . 6
3. Difference between MPLS and GMPLS protocols . . . . . . . . . . . 6
3.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Control plane/data plane separation . . . . . . . . . . . . . 8
3.4. Bi-directional LSP . . . . . . . . . . . . . . . . . . . . . . 9
4. Required mechanism . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Single-area . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1.1. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Multi-area . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. LSP nesting . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. LSP converting . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2.1. MPLS->GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2.2. GMPLS->MPLS . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2.3. ERO/RRO processing . . . . . . . . . . . . . . . . . . . . 14
4.2.3. LSP stitching . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.4. Discovery of GMPLS signalling capability . . . . . . . . . . 15
5. MPLS-GMPLS-MPLS reference model . . . . . . . . . . . . . . . . . 16
5.1. LSP nesting . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. Basic description . . . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Traffic demand change . . . . . . . . . . . . . . . . . . . . 16
5.1.3. Nest of FAs . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.4. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. LSP converting/LSP stitching . . . . . . . . . . . . . . . . . 18
5.2.1. LSP One-to-one relationship . . . . . . . . . . . . . . . . . 18
5.2.2. LSP Traffic demand change . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative references . . . . . . . . . . . . . . . . . . . . . 19
8.2. Informative references . . . . . . . . . . . . . . . . . . . . 20
9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Intellectual Property Rights Notices . . . . . . . . . . . . . . 22
10.1. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 22
[Page 1]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004
[Page 2]