IETF Internet Draft T. Otani
Proposed status: Informational KDDI R&D Labs
Expires: Aug. 2005 K. Kumaki
KDDI
S. Okamoto
NTT
January 2005
GMPLS Inter-domain Traffic Engineering Requirements
Document: draft-otani-ccamp-interas-gmpls-te-02.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668. "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.
Abstract
This draft provides requirements for the support of generalized
multi-protocol label switching (GMPLS) inter-domain traffic
engineering (TE). Its main objective is to present the differences
between MPLS inter-domain TE and GMPLS inter-domain TE. This draft
covers not only GMPLS Inter-domain architecture but also functional
requirements in terms of GMPLS signaling and routing in order to
specify these in a GMPLS Inter-domain environment.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
T. Otani et al. Informational - Expires January 2005 1
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
1. Introduction....................................................3
2. Conventions used in this document...............................3
3. Assumed network model...........................................4
4. Requirement of exchanging TE information across domain boundaries6
5. Requirement for GMPLS inter-domain TE signaling, routing and
management.........................................................9
6. Security consideration.........................................14
7. Acknowledgement................................................14
8. Intellectual property considerations...........................14
9. Informative references.........................................14
Author's Addresses................................................15
Document expiration...............................................16
Copyright statement...............................................16
T. Otani et al. Informational - Expires January 2005 2
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
1. Introduction
Initial efforts of MPLS/GMPLS traffic engineering mechanism were
focused on solving the problem within an Autonomous System (AS).
Service Providers have come up with requirements for extending TE
mechanisms across the domains (ASes as well as areas) [Inter-domain].
It discusses requirements for inter-domain Traffic Engineering
mechanism with focus on packet MPLS networks and GMPLS packet switch
capable (hereinafter MPLS). This document complements [Inter-domain]
by providing some consideration for non-packet switch capable GMPLS
networks (hereinafter GMPLS) scalability and operational efficiency
in such a networking environment.
TE information exchanged over domains for signaling and routing GMPLS
Label Switched Paths (LSPs) is more stringent than that of MPLS LSPs
[MPLS-AS] from the point of an effective operation. This is because
in order to dynamically or statically establish GMPLS LSPs, the
additional TE information, e.g., interface switching capability, link
encoding, protection, and so forth must be considered. Operators may
usually use different switching capable nodes and TE links with
different encoding type and bandwidth, decided by their business
strategy and such TE information exchange is expected to improve
operational efficiency in GMPLS-controlled networks.
In terms of signaling, GMPLS signaling must operate over multiple
domains using exchanged TE information or a statistically configured
domain-to-domain route. This signaling request should take into
account bi-directionality, switching capability, encoding type, SRLG,
and protection attributes of the TE links spanned by the path, as
well as LSP encoding type and switching type for the end points.
Furthermore, GMPLS LSP nesting may be applicable at the GMPLS domain
borders and should be considered accordingly.
This document provides the requirements for the support of GMPLS
inter-domain TE, investigates the necessity of dynamic or static TE
information exchange between GMPLS-controlled domains and describes
the TE link parameters for this routing operation. This document
also outlines GMPLS inter-domain architecture, and provides
functional requirements in terms of GMPLS signaling, routing and
management in order to specify these in a GMPLS inter-domain
environment.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
T. Otani et al. Informational - Expires January 2005 3
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
3. Assumed network model
3.1 GMPLS inter-domain network model
Figure 1 depicts a typical network, consisting of several GMPLS
domains, assumed in this document. D1, D2, D3 and D4 have multiple
GMPLS inter-domain connections, and D5 has only one GMPLS inter-
domain connection. These domains follow the definition in [inter-
domain].
+---------+
+---------|GMPLS D2|----------+
| +----+----+ |
+----+----+ | +----+----+ +---------+
|GMPLS D1| | |GMPLS D4|---|GMPLS D5|
+----+----+ | +----+----+ +---------+
| +----+----+ |
+---------|GMPLS D3|----------+
+---------+
Figure 1: GMPLS Inter-domain network model
Each domain is configured using various switching and link
technologies defined in [Arch] and an end-to-end route needs to
respect TE link attributes like multiplexing type, encoding type,
etc., making the problem a bit different from the case of classical
(packet) MPLS. In order to route from one GMPLS domain to another
GMPLS domain appropriately, each domain needs to advertise additional
TE information, while concealing its internal topology information.
In addition, a signaling mechanism is required to specify a route
consisting of multiple domains, while respecting the end-pointÆs
encoding, switching and payload type. Section 4 describes the TE link
attributes that need to be exchanged across the domain boundary in
detail.
3.2 Comparison between a GMPLS inter-domain and a MPLS inter-domain
(1) GMPLS network model
To investigate the difference between a GMPLS inter-domain and an
MPLS inter-domain network, we assume the network model shown in Fig.
2. Without loss of generality, this network model consists of two
GMPLS domains. The GMPLS domain border nodes (A3, A4, B1, B2) are
connected via traffic engineering (TE) links (A3-B1 and A4-B2). These
inter-domain TE links are assumed to have a certain amount of
bandwidth (bw), e.g., 2.5Gbit/s, 10Gbit/s, etc. Moreover, each nodes
in both domain 1 and domain 2 can support x and y switching
capabilities (e.g., x or y means TDM, Lambda or fiber). The edge node
of the network (possibly A1, A2, B3, and B4) may also have the
switching capability of packet (PSC1-4). Moreover, each TE link has a
z or w encoding type (z or w means SONET/SDH, Lambda, Ethernet, etc.).
T. Otani et al. Informational - Expires January 2005 4
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
|
+-------+ z-enc. +-------+ z-enc. +-------+ z-enc. +-------+
|A1,x-SC|----//----|A3,x-SC|-----------|B1,y-SC|----//----|B3,y-SC|
+-------+ bw-1 +-------+ bw-1 +-------+ bw-1 +-------+
| | | | |
=bw-1 =bw-1 | =bw-1 =bw-1
|z-enc. |z-enc. | |z-enc. |z-enc.
| | | | |
+-------+ w-enc. +-------+ w-enc. +-------+ w-enc. +-------+
|A2,x-SC|----//----|A4,x-SC|-----------|B2,y-SC|----//----|B4,y-SC|
+-------+ bw-2 +-------+ bw-2 +-------+ bw-2 +-------+
|
GMPLS domain 1 | GMPLS domain 2
Figure 2: GMPLS Inter-domain network model (1)
Between GMPLS domain border nodes, the routing information is
statically or dynamically exchanged. Link management protocol (LMP)
[LMP] may be applied to maintain and manage TE links between GMPLS
domain border nodes.
In general, the attributes of two TE-Links (A1-B3 and A4-B2) between
domain border nodes as well as switching capability of each border
node shall not be always same. Therefore, GMPLS nodes shall need to
identify the attributes of these TE-Links and border nodes in order
to create LSP over multiple domains. At present, GMPLS/ MPLS
technology does not provide the functionality to discriminate such
attributes. Furthermore, these GMPLS specific requirements for inter-
domain traffic engineering are not described in [Inter-domain].
(2) MPLS network model
In the packet MPLS network, we can assume the MPLS inter-domain
network model as shown in Figure 3. There are no routing constraints
such as switching capability and encoding type, compared to the GMPLS
inter-domain network model. All nodes have the same switching
capability of packet.
|
+----+ +----+ | +----+ +----+
| A1 |----//----| A3 |---------| B1 |----//----| B3 |
+----+ 2.5G +----+ 2.5G +----+ 2.5G +----+
| | | | |
=2.5G =2.5G | =2.5G =2.5G
| | | | |
+----+ +----+ | +----+ +----+
| A2 |----//----| A4 |---------| B2 |----//----| B4 |
+----+ 10G +----+ 10G +----+ 10G +----+
|
MPLS domain 1 | MPLS domain 2
T. Otani et al. Informational - Expires January 2005 5
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
Figure 3: MPLS Inter-domain network model
In the following section, we consider an MPLS or GMPLS path setup
from an edge node in domain 1 to an edge node in domain 2.
4. Requirement of exchanging TE information across domain boundaries
In this section, we describe the TE attributes that needs to be
exchanged across the domain boundaries for computation of GMPLS Paths.
4.1 Interface Switching Capability
A constraint of bandwidth in a GMPLS controlled network is different
from that in an IP/MPLS network. In Figure 3, two TE links with
different values of bandwidth such as 2.5Gbit/s and 10Gbit/s are
assumed. If an MPLS LSP with 2.5Gbit/s bandwidth is established from
A2 to B4 in Figure 3, two sets of TE links (that is two possible
paths) can be selected (A2-A4-B2-B4 and A2-A1-A3-B1-B3-B4).
In the case of GMPLS inter-domains, the ingress node needs to know
the switching capabilities supported in each domain, while computing
a route for a GMPLS-LSP across multiple domains. If the switching
capabilities are exchanged across the domain boundaries, the ingress
node can determine the appropriate next-hop domain that is capable of
supporting the requesting switching capability.
In the example of Figure 4, we assume a switching capability as
lambda and an encoding type as lambda. The bandwidth of each TE link
is, for example, corresponding to the transponderÆs bit rate of each
DWDM channel. In this case, both inter-domain links may be acceptable
from A2 to B4 if only TE information within each domain is considered.
However, a GMPLS LSP with 2.5Gbit/s bandwidth can not be established
over a set of TE links (A2-A4-B2-B4) because all nodes support only
LSC which can not deal with sub-rate switching, and the 10Gbit/s TE
link can only support a GMPLS LSP with 10Gbit/s. The set of TE links
(A2-A1-A3-B1-B3-B4) must be used instead so as to route it over the
inter-domain link of A3-B1.
If multiple GMPLS routes exist for a given destination via different
domains, a path should be selected satisfying these routing
constraints, in addition to the conventional attributes which the
intra-domain routing protocols. Although an operator may want to
specify a domain border node explicitly for such a destination, this
TE information exchange will improve operational efficiency in GMPLS-
controlled networks. Therefore, not only intra-domain routing
protocols [GMPLS-Routing] but also inter-domain routing protocol
needs to advertise some TE parameters.
T. Otani et al. Informational - Expires January 2005 6
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
|
+------+ 2.5G +------+ 2.5G +------+ 2.5G +------+
|A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC|
+------+ Lambda +------+ Lambda +------+ Lambda +------+
| | | | |
2.5G=Lambda 2.5G=Lambda | 10G=Lambda 2.5G=Lambda
| | | | |
+------+ 10G +------+ 2.5G +------+ 10G +------+
|A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC|
+------+ Lambda +------+ Lambda +------+ Lambda +------+
|
GMPLS domain 1 | GMPLS domain 2
Figure 4: GMPLS inter-domain network model (2)
4.2 Bandwidth Policy
The advertisement of the bandwidth for traversing non-local domains
is strongly dependent on the operational policy in each GMPLS domain.
The resource available for different domains may be advertised over
GMPLS inter-domains, although the actual local bandwidth is more than
that for different domains. The GMPLS domain border nodes have the
functionality to control the advertised resource bandwidth to reach a
destination. For example, even if 4 times OC-48 bandwidth exists to a
destination in one GMPLS domain, the domain may advertise only twice
OC-48 bandwidth to another GMPLS domain, following the mutual policy
between these two domains. Thus, inter-domain reachability
information needs to be enhanced to include bandwidth information.
4.3 Encoding type
In addition of the link switching type, an end-to-end GMPLS LSP needs
to have the same encoding type at all intermediate hops. In this
section, we discuss the need for exchanging link encoding types
across the domain boundaries.
The example depicted in Figure 5 is considered where TE links with a
different encoding type in a GMPLS Inter-domain network are assumed.
In this case, differing from the case of a packet MPLS inter-domain
network, a GMPLS LSP with a specific encoding type must be
established to satisfy this constraint. Since physical layer
technologies used to form TE links limit the signal encoding type to
be transported, the ingress node should consider this by obtaining TE
parameters exchanged between GMPLS-controlled inter-domains. In this
case, both inter-domain links may be acceptable for routing from A2
to B4 if only TE information within each domain is considered. The
set of TE links (A2-A1-A3-B1-B3-B4) must be used instead so as to
route over the inter domain-link of A3-B1, satisfying the constraint
of the encoding type. Therefore, inter-domain reachability
information needs to be enhanced to include encoding type information.
T. Otani et al. Informational - Expires January 2005 7
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
|
+------+ +------+ | +------+ +------+
|A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC|
+------+ SONET +------+ SONET +------+ SONET +------+
| | | | |
=SONET =SONET | =lambda =SONET
| | | | |
+------+ +------+ | +------+ +------+
|A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC|
+------+ lambda +------+ SONET +------+ lambda +------+
|
GMPLS domain 1 | GMPLS domain 2
Figure 5: GMPLS inter-domain network model (3)
4.4 Hybrid case
In Figure 6, we consider a mixed case of 4.1, 4.2 and 4.3, and assume
two domains: Domain 1 consisting of GMPLS nodes with TDM-SC and TE
links with SONET/SDH encoding type, and domain 2 consisting of GMPLS
nodes with LSC and TE links with lambda encoding type. GMPLS nodes in
domain 2 support sub-rate switching, for example, of 2.5Gbit/s.
|
+------+ 2.5G +------+ 2.5G +------+ 2.5G +------+
|A1,TSC|----//----|A3,TSC|-----------|B1,LSC|----//----|B3,LSC|
+------+ SONET +------+ SONET +------+ Lambda +------+
| | | | |
2.5G=SONET 2.5G=SONET | 10G=Lambda 2.5G=Lambda
| | | | |
+------+ 10G +------+ 2.5G +------+ 10G +------+
|A2,TSC|----//----|A4,TSC|-----------|B2,LSC|----//----|B4,LSC|
+------+ SONET +------+ SONET +------+ Lambda +------+
|
GMPLS domain 1 | GMPLS domain 2
Figure 6: GMPLS Inter-domain network model (4)
If a GMPLS LSP with 2.5Gbit/s is established from A2 to B4, the
ingress node should know not only the reachability of B4 in domain 2,
but also the switching capability of nodes in domain 2. In this case,
both inter-domain links may be acceptable for routing from A2 to B4
if only TE information within each domain is considered. However,
since the switching capability supported in each domain is different,
the set of TE links (A2-A1-A3-B1-B3-B4) must be used so as to route
over the inter domain-link of A3-B1. Therefore, an end-point
(reachability) list such as node IDs, interface addresses, interface
T. Otani et al. Informational - Expires January 2005 8
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
IDs per switching capability is very useful and may be advertised
over GMPLS domains.
4.5 SRLG
To configure a secondary LSP in addition to a primary LSP over
multiple GMPLS domains, the parameter of Shared Risk Link Group
(SRLG) is very significant. By introducing this parameter, the source
node can route these LSPs so as to across the different domain border
node as well as satisfy a SRLG constraint. Although this SRLG is
supported and defined within domains, the mechanism to maintain
consistency of SRLG must be considered in a GMPLS inter-domain TE
environment.
There are cases where two different SPs may be sharing the same fate
(facility) for TE links within domains administrated by them. However,
presently there is no mechanism to allow SRLG to have global
significance; SRLG administration is completely up to interconnected
SPs.
In this document we identify that, in order to guarantee the SRLG
diversity requirement, the SRLGs in an inter-domain TE environment
are required to be globally unique.
4.6 Protection Type
To guarantee the GMPLS LSP's resiliency over multiple GMPLS domains,
the protection type in each domain should be carefully selected so as
to satisfy resilient requirement of the LSP as an end-to-end manner.
This enables us to establish a LSP with a protection mechanism per
domain-basis, such as link or node protection. Each GMPLS domain will
provide a type of the protection to a destination within itself.
Otherwise, an end-to-end recovery may be provided by calculating at
the source node with the consideration of SRLG. As the same with SRLG
case, protection type administration is also up to interconnected SPs.
Therefore, inter-domain reachability information needs to be enhanced
to include protection type information.
5. Requirement for GMPLS inter-domain TE signaling, routing and
management
5.1 Requirement for GMPLS inter-domain signaling for the support of
TE
GMPLS inter-domain signaling must establish GMPLS LSPs over GMPLS
multiple domains with a dynamic calculation of the domain-to-domain
route and GMPLS domain border nodes. It also must support to
explicitly specify domain-to-domain routes, domain border nodes and
GMPLS nodes. Moreover, specifying loose GMPLS nodes including GMPLS
T. Otani et al. Informational - Expires January 2005 9
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
domain border nodes must be supported in GMPLS signaling. The domain
border node received GMPLS signaling message from a source node in a
different domain should support recalculation mechanisms to specify
the route within its domain, such as RSVP route expansion technique,
followed by GMPLS inter-domain path computation.
5.1.1 GMPLS per-domain basis path calculation support
Firstly, GMPLS per-domain basis path calculation is described. In
this path calculation model, a GMPLS LSP head-end specifies GMPLS
domain border nodes as loose hops to tail-end statically or
dynamically [Path-comp]. The route information may be learned from
the GMPLS EGP. The source node also calculates the intermediate nodes
to reach the selected egress domain border node.
Once the GMPLS path message has traversed to the connecting domain
border node in the adjacent domain, another path calculation is
conducted, for example, by RSVP-TE expansion to reach its destination,
otherwise to reach an egress border node transiting to another domain.
This path calculation will not necessarily guarantee the domain-to-
domain path optimality.
5.1.2 GMPLS end-to-end basis path calculation support
GMPLS end-to-end basis path calculation is indicated next. In this
path calculation, the GMPLS LSP head-end specifies an domain-to-
domain route (for example, domain1-domain2-domain4-domain5 in Figure
1) as well as the intermediate nodes to the egress domain border node
in its belonging domain. The domain border node in an adjacent domain
will determine intermediate nodes followed by the specified domain
path route. This path calculation will guarantee the domain path
optimality, however, not necessarily guarantee end-to-end path
optimality.
5.1.3 Fast Recovery support
Fast recovery operation based on the end-to-end [e2e] and segment
[SEG-RECOVERY] based approach should be supported over multiple GMPLS
domains, considering inter-domain link, SRLG and node diversity.
These types of operation should interoperate with GMPLS intra-domain
TE fast recovery mechanism. The domain border node may respond
indicating a path setup error if it does not support the
protection/restoration mechanism which is requested by the signaling
messages generated from the source node in the different domain.
Depending on the recovery mode, re-optimization or revertive
operations should be supported.
T. Otani et al. Informational - Expires January 2005 10
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
5.1.4 Policy Control
Depending on the policy between domains, the domain border GMPLS
nodes may reject GMPLS inter-domain signaling messages if the
unapproved objects are included.
5.2 Requirement for GMPLS Inter-domain routing for the support of TE
In IP/MPLS networks, inter-AS routing such as the EGP is well-defined
and widely deployed. However, the need for such inter-domain routing
extension for MPLS TE does not exist at present. Nonetheless, inter-
domain routing extensions are required to support multiple GMPLS
domains as well as for layer 1 VPN [L1VPN]. GMPLS extension for
multi-domain TE is required for guaranteeing inter-domain GMPLS
constraints, when attempts are made to establish GMPLS LSPs over
multiple domains as discussed in section 4.
5.2.1 Reachability information exchange
GMPLS inter-domain routing mechanism must support the exchange of
reachability information over each domain. Reachability information
includes:
(1) Node ID
(2) Interface address
(3) Interface ID
The reachability information must be advertised in accordance with
their belonging domain information in order to calculate the GMPLS
LSP over multiple domains. The reachability information may be
aggregated depending on the domainÆs policy.
In addition to these,
(4) VPN-associated information
may be exchanged as a part of routing information to support L1-VPN
functionality.
The scalability of inter-domain routing should be considered in
designing GMPLS extensions to allow exchange of some TE information
in addition to the above reachability information. Furthermore, the
GMPLS inter-domain routing must be designed to achieve such operation
that defects in one domain do not affect the scalability of an intra-
domain routing of IGPs in other domains, although the GMPLS inter-
domain routing must promptly advertise the failure within the domain,
ensuring the GMPLS inter-domain connection establishment.
GMPLS inter-domain routing must basically follow the GMPLS
architecture [Arch], including the support of its exchange over out
of band control channel.
T. Otani et al. Informational - Expires January 2005 11
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
5.2.2 TE parameters exchange
Coinciding with MPLS Inter-domain work, the TE parameters for GMPLS
Inter-domain routing are considered to be added.
A GMPLS domain border node is required to announce the following
parameters in addition to reachability information of node IDs,
interface addresses and interface IDs.
(1) Interface switching capability
(1-1)Bandwidth
A. Total link bandwidth
B. Max./Min. Reservable bandwidth
C. Maximum LSP bandwidth
D. minimum LSP Bandwidth
C. Unreserved bandwidth
(1-2)Switching capability: PSC1-4, L2SC, TDM, lambda, LSC, FSC
(2) Bandwidth Encoding type: As defined in [RFC3471], e.g., Ethernet,
SONET/SDH, Lambda.
(3) SRLG (Global view)
(4) Protection type
As mentioned in section 4.4, an end-point (reachability) list
consisting of node IDs, interface addresses, interface IDs per
switching capability is formed in order to be advertised over GMPLS
domains.
For stitched, nested and contiguous GMPLS LSPs over multiple domains,
a GMPLS LSP created within a domain will be announced as a (transit)
link resource exposed to different domains with appropriate TE
parameters, while concealing intermediate nodes or interface
addresses. The GMPLS inter-domain routing must support this
functionality and locally configure this on the domain border nodes.
To ensure future interworking operation between GMPLS and MPLS, the
GMPLS inter-domain routing should be also applicable to MPLS inter-
domain TE (bandwidth) information exchange.
5.2.3 Reachability information redistribution requirement
GMPLS inter-domain routing must provide redistribution mechanisms
within the domain in a scalable manner. These information
redistribution mechanisms must be designed to achieve such operation
that a defect in a domain does not affect the scalability of intra-
domain routing in a different domain, although the GMPLS inter-domain
routing must promptly advertise the failure within the domain,
ensuring the GMPLS inter-domain connection establishment.
Mechanisms for redistributing GMPLS TE information within the GMPLS
domain can be, for example, a path computation element (PCE), I-BGP
session, or re-injection to IGP. Especially, it is useful to adopt
T. Otani et al. Informational - Expires January 2005 12
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
GMPLS end-to-end basis path calculation. PCE based requirement may be
incorporated with the PCE Architecture document [PCE].
GMPLS inter-domain routing must have the functionality to consider
any policies for controlling TE routing information to be flooded,
which will be defined between domains on a business or operational
strategy basis. GMPLS inter-domain routing policy should be able to
be changed and configured on a per domain basis. This policy control
especially in terms of switching capability may be applicable to the
extensions of hierarchical routing. Each domain should control the
advertisement of the switching capability or re-advertisement of
received switching capability.
5.3 GMPLS inter-domain TE Management
5.3.1 GMPLS inter-domain TE Fault Management
To maintain the control channel session as well as to provide fault
isolation mechanism, link management mechanisms such as [LMP] should
be applied to TE links between GMPLS domain border nodes. To validate
LSPs created over multiple domains, a generic tunnel tracing protocol
(GTTP) may be applied [GTTP].
5.3.2 GMPLS inter-domain TE MIB Requirements
GMPLS inter-domain TE Management Information Bases must be supported
to manage and configure GMPLS inter-domain TE in terms of GMPLS LSPs,
routing, TE links and so forth. These MIBs should extend the
existing series of MIBs [GMPLS-TEMIB] to accommodate following
functionalities;
- To manage GMPLS LSP characteristics at the tunnel head-end as well
as any other points of the TE tunnel.
- To include both IPv4/v6 and domain identifier, or only domain
identifier in the subobjects of GMPLS RSVP ERO. A label may be
included in it. The example of the object is as follows;
EXPLICIT_ROUTE class object:
Address1 (loose IPv4 address prefix,label, /domain1)
Address2 (loose IPv4 address prefix,label, /domain1)
domain2 (domain number)
Address3 (loose IPv4 address prefix,label, /domain3)
Address4 (loose IPv4 address prefix,label, /domain3)-destination
Or
Address1 (loose IPv4 address prefix,label, /domain1)
Address2 (loose IPv4 address prefix,label, /domain1)
Address3 (loose IPv4 address prefix,label, /domain2)
Address4 (loose IPv4 address prefix,label, /domain2)
Address5 (loose IPv4 address prefix,label, /domain3)
Address6 (loose IPv4 address prefix,label, /domain3)-destination
T. Otani et al. Informational - Expires January 2005 13
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
- Inclusion of recording subobjects such as interface IPv4/v6
addresses, domain identifier, a label, a node-id and so on in
the RRO of the RESV message, considering the established policies
between GMPLS domains.
6. Security consideration
GMPLS inter-domain TE should be implemented under a certain security
consideration such as authentication of signaling and routing on the
control plane as well as a data plane itself. Indeed, this will not
change the underlying security issues.
7. Acknowledgement
The author would like to express the thanks to Noaki Yamanaka, Kohei
Shiomoto, Wataru Imajuku, Michiaki Hayashi, Zafar Ali, Adrian Farrel
and Tomonori Takeda for their comments.
8. Intellectual property considerations
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 implementers 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.
9. Informative references
[Inter-domain] A. Farrel, et al, "A framework for inter-domain MPLS
traffic engineering", draft-farrel-ccamp-inter-
fomain-framework-00.txt, April 2004.
[MPLS-AS] R. Zhan, et al, "MPLS Inter-AS Traffic Engineering
requirements", draft-ietf-tewg-interas-mpls-te-req-
09.txt, September 2004 (work in progress).
T. Otani et al. Informational - Expires January 2005 14
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
[LMP] J. P. Lang, et al, "Link Management Protocol (LMP)",
draft-ietf-lmp-10.txtüE October 2003.
[GMPLS-Routing] K. Kompella, et al, "Routing Extensions in Support of
Generalized Multi-Protocol Label Switching", draft-
ietf-ccamp-gmpls-routing-09.txt, October 2003.
[L1VPN] T. Takeda, et al, "Framework for Layer 1 Virtual
Private Networks", draft-takeda-l1vpn-framework-
01.txt, July 2004.
[PCE] A. Farrel,et al, "Path Computation Element (PCE)
Architecture", draft-ash-pce-architecture-00.txt,
September 2004.
[Arch] E. Mannie, et al, "Generalized Multi-Protocol Label
Switching Architecture", draft-ietf-ccamp-gmpls-
architecture-07.txt, May, 2003.
[Path-comp] J. P. Vasseur, et al, "Inter-domain Traffic
Engineering LSP path computation methods", draft-
vasseur-ccamp-inter-domain-path-comp-00.txt, July
2004.
[GMPLS-ROUTING] K. Kompella, et al, "Routing Extensions in Support of
Generalized Multi-Protocol Label Switching", draft-
ietf-ccamp-gmpls-routing-09.txt.
[e2e] J. P. Lang, et al, "RSVP-TE Extensions in support of
End-to-End GMPLS-based Recovery", draft-ietf-ccamp-
gmpls-recovery-e2e-signaling-01.txt, May, 2004.
[SEG-RECOVERY] L. Berger, et al, "GMPLS Based Segment Recovery",
draft-ietf-ccamp-gmpls-segment-recovery-00.txt, March
2004.
[GTTP] R. Bonica, et al, "Generic Tunnel Tracing Protocol
(GTTP) Specification", draft-ietf-ccamp-tunproto-
01.txt, Sept. 2004.
[GMPLS-TEMIB] T. Nadeau, et al, "Generalized Multi-Protocol Label
Switching Traffic Engineering Management Information
Base", draft-ietf-ccamp-gmpls-te-mib-06.txt, Oct 2004.
Author's Addresses
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357
Saitama, 356-8502. Japan Email: otani@kddilabs.jp
Kenji Kumaki
KDDI Corporation
GARDEN AIR TOWER,3-10-10,Iidabshi Phone: +81-3-6678-3103
Chiyoda-ku,Tokyo, 102-8460. Japan Email: ke-kumaki@kddi.com
Satoru Okamoto
NTT Network Service System Laboratory
3-9-11 Midori-cho, Musashino-shi, Phone: +81-422-59-4353
Tokyo, 180-8585. Japan Email: okamoto.satoru@lab.ntt.co.jp
T. Otani et al. Informational - Expires January 2005 15
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt February
2005
Document expiration
This document will be expired in Aug. 2005, unless it is updated.
Copyright statement
"Copyright (C) The Internet Society (year). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
T. Otani et al. Informational - Expires January 2005 16