IETF Internet Draft T. Otani
Proposed status: Informational M. Hayashi
Expires: January 2005 KDDI R&D Labs
S. Okamoto
NTT
July 2004
TE parameters to be exchanged between GMPLS-controlled ASes
Document: draft-otani-ccamp-interas-gmpls-te-00.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 investigates the difference between MPLS Inter-AS traffic
engineering (TE) and GMPLS Inter-AS TE and describes requirements of
TE parameters to be dynamically or statically exchanged between
Generalized Multiprotocol Label Switching (GMPLS) inter-ASes.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1. Introduction....................................................3
2. Conventions used in this document...............................3
3. Assumed network model...........................................3
T. Otani et al. Informational - Expires January 2005 1
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004
4. Clarification of necessity of dynamic or static information
exchange between GMPLS Inter ASes..................................5
5. Requirement of TE parameters to be supported for EGP............7
6. Security consideration..........................................8
7. Intellectual property considerations............................8
8. Normative references............................................8
Author's Addresses.................................................9
Document expiration................................................9
Copyright statement................................................9
T. Otani et al. Informational - Expires January 2005 2
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004
1. Introduction
Since basic sets of GMPLS protocols have been so far standardized,
CCAMP WG proposed to start to discuss about MPLS/GMPLS inter-domain
traffic engineering (TE) [Inter-domain]. To proceed with this work,
scalability and operational efficiency considering an actual
networking environment is quite significant.
TE information exchanged over domains (areas or ASes) for controlling
GMPLS Label Switched Paths (LSPs) is more stringent than that of MPLS
LSPs [MPLS-AS] from the point of an effective operation, because in
order to dynamically or statically establish GMPLS LSPs, the
additional TE information to the conventional MPLS-TE must be
considered to be exchanged, such as switching capability, bandwidth
encoding, and so forth.
This document describes the necessity of dynamic or static TE
information exchange between GMPLS-controlled ASes as well as the
requirement of TE parameters for this routing operation.
2. Conventions used in this document
In this document the steps for walking a pull-down tree are indented
on subsequent lines. This allows abbreviation rather than a barrage
of 'then click' or 'select' strings in a paragraph form. Example:
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].
3. Assumed network model
3.1 GMPLS network model
Here, we assumed the below network model consisting of two GMPLS ASes.
Each GMPLS AS is connected via traffic engineering (TE) links with a
certain value of bandwidth (bw is, for example, 2.5Gbit/s, 10Gbit/s,
etc.) between different GMPLS AS boarder nodes (A3-B1 and A4-B2).
Moreover, each nodes in both AS 1 and AS 2 support x and y switching
capability (x or y means TDM, Lambda or lambda). The edge node of
the network (possibly A1, A2, B3, B4) may have the switching
capability of packet (psc). Moreover, each TE link has a z or w
encoding type (z or w means SONET/SDH, Lambda, Ethernet, etc).
|
+-------+ 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
T. Otani et al. Informational - Expires January 2005 3
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004
|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 AS 1 | GMPLS AS 2
Figure 1: GMPLS Inter AS network model(1)
Between GMPLS AS 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 AS border
nodes.
In general, the attributes of two TE-Links (A1-B3 and A4-B2) between
AS border nodes as well as switching capability of each border node
shall not be always same. Therefore, GMPLS nodes shall identify the
attributes of these TE-Links and border nodes in order to create LSP
over multiple ASes. The conventional MPLS technology does not
provide the functionality to discriminate such attributes.
3.2 MPLS network model
In the conventional MPLS network, we can assume MPLS Inter AS network
model as below. There are no routing constraints such as switching
capability and encoding type, compared to the GMPLS Inter AS 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 AS 1 | MPLS AS 2
Figure 2: MPLS Inter AS network model
In the following section, we consider a MPLS or GMPLS path setup from
an edge node in AS 1 to an edge node in AS2.
T. Otani et al. Informational - Expires January 2005 4
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004
4. Clarification of necessity of dynamic or static information exchange
between GMPLS Inter ASes
4.1 Interface Switching capability
A constraint of bandwidth in GMPLS controlled network is different
from that of IP/MPLS network. In Figure 2, two TE links with
different values of bandwidth such as 2.5 Gbit/s and 10 Gbit/s are
assumed. If an MPLS LSP with 2.5 Gbit/s bandwidth is established
from A2 to B4 in Figure 2, two set of TE links (A2-A4-B2-B4 and A2-
A1-A3-B1-B3-B4) can be selected.
In the case of GMPLS inter ASes, the ingress node is beneficial to
know switching capabilities supported in each AS when a route for a
GMPLS-LSP across multiple ASes is computed. For a request of GMPLS-
LSP setup, the ingress node determine the appropriate next-hop AS,
which is capable of desired switching capability, if such information
is exchanged between GMPLS ASes.
Here, we assume a switching capability as Lambda and an encoding type
as lambda, as shown in Figure 3. The bandwidth of each TE link is,
for example, corresponding to the transponderÆs bit rate of each DWDM
channel.
As shown in Figure 3, a GMPLS LSP with 2.5 Gbit/s 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
10 Gbit/s TE link can only support a GMPLS LSP with 10 Gbit/s.
If multiple GMPLS routes exist for a destination in a different AS, a
path should be selected satisfying these routing constraints, in
addition to the conventional EGP attributes. Although an operator
may want to specify the AS border node explicitly for such a
destination, this TE information exchange will improve operational
efficiency in GMPLS-controlled networks. Therefore, not only IGP
[GMPLS-Routing] but also EGP should advertise this TE parameter.
|
+------+ 2.5G +------+ 2.5G +------+ 2.5G +------+
|A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC|
+------+ Lambda +------+ Lambda +------+ Lambda +------+
| | | | |
2.5G=Lambda 2.5G=Lambda | 2.5G=Lambda 2.5G=Lambda
| | | | |
+------+ 10G +------+ 10G +------+ 10G +------+
|A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC|
+------+ Lambda +------+ Lambda +------+ Lambda +------+
|
GMPLS AS 1 | GMPLS AS 2
Figure 3: GMPLS Inter AS network model (2)
T. Otani et al. Informational - Expires January 2005 5
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004
4.2 Bandwidth
The advertisement of the available bandwidth over GMPLS inter ASes is
strongly dependent on the operational policy in each GMPLS ASes. The
resource available for different ASes may be advertised over GMPLS
inters ASes, although the actual bandwidth is more than that for
different ASes. The GMPLS Border nodes have the functionality to
control the advertised resource bandwidth reached to a destination.
For example, even if 4 times OC-48 bandwidth exists to a destination
in one GMPLS AS, the AS may advertise only twice OC-48 bandwidth to
another GMPLS AS, following the mutual policy between these two ASes.
4.3 Encoding type
Here, TE links with a different encoding type in a GMPLS Inter AS
network are assumed as in Figure 3. In this case, differing from the
case of a MPLS inter AS 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 limits the signal encoding
type to be transported, the ingress node should consider this by
obtaining TE parameters exchanged between GMPLS-controlled inter-ASes
|
+------+ +------+ | +------+ +------+
|A1,LSC|----//----|A3,LSC|-----------|B1,LSC|----//----|B3,LSC|
+------+ SONET +------+ SONET +------+ SONET +------+
| | | | |
=SONET =SONET | =SONET =SONET
| | | | |
+------+ +------+ | +------+ +------+
|A2,LSC|----//----|A4,LSC|-----------|B2,LSC|----//----|B4,LSC|
+------+ lambda +------+ lambda +------+ lambda +------+
|
GMPLS AS 1 | GMPLS AS 2
Figure 4: GMPLS Inter AS network model (3)
4.4 Mixed case
Here, we consider a mixed case of 4.1, 4.2 and 4.3, and assume two
ASes: AS 1 consisting of GMPLS nodes with LSC and TE links with
Lambda encoding type at 2.5 Gbit/s, and AS 2 consisting of GMPLS
nodes with TDM-SC and TE links with SONET/SDH encoding type at 10
Gbit/s. GMPLS nodes in AS 2 support sub-rate switching, for example,
of 2.5 Gbit/s.
|
T. Otani et al. Informational - Expires January 2005 6
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004
+------+ 2.5G +------+ 2.5G +------+ 10G +------+
|A1,LSC|----//----|A3,LSC|-----------|B1,TSC|----//----|B3,TSC|
+------+ Lambda +------+ SONET +------+ SONET +------+
| | | | |
2.5G=Lambda 2.5G=Lambda | 10G=SONET 10G=SONET
| | | | |
+------+ 2.5G +------+ 10G +------+ 10G +------+
|A2,LSC|----//----|A4,LSC|-----------|B2,TSC|----//----|B4,TSC|
+------+ Lambda +------+ SONET +------+ SONET +------+
|
GMPLS AS 1 | GMPLS AS 2
Figure 5: GMPLS Inter AS network model (4)
If a GMPLS LSP with 2.5 Gbit/s is established from A2 to B3, the
ingress node should know not only the reachability of B3 in AS 2 but
also the sub-rate (TDM) switching capability of nodes in AS 2 and
available bandwidth to the destination. In this sense, an end-point
(reachability) list consisting of node IDs, interface addresses,
interface IDs per switching capability is very useful and may be
advertised over GMPLS ASes.
Operators may usually use a different switching capable nodes and
different TE link 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.
4.5 SRLG
To configure a secondary LSP in addition to a primary LSP over
multiple GMPLS ASes, Shared Risk Link Group (SRLG) parameter is very
significant. By introducing this parameter, the source node can
route these LSPs so as to across the different AS boarder node as
well as satisfy a SRLG constraint.
The SRLG over multiple ASes may be determined as a globally unique in
order to guarantee the SRLG diversity.
5. Requirement of TE parameters to be supported for EGP
Coinciding with MPLS Inter AS work, the TE parameters for GMPLS Inter
AS is considered to be added.
A GMPLS AS border node is required to announce the below parameters
in terms of node IDs, interface addresses and interface IDs, of which
reachability is advertised via EGP.
(1) Interface switching capability
(1-1)Bandwidth
T. Otani et al. Informational - Expires January 2005 7
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004
A. Total link bandwidth
B. Max./Min. Reservable bandwidth
C. Unreserved bandwidth
(1-2)Switching capability: TDM, lambda, FSC
(2) Bandwidth Encoding: Ethernet, SONET/SDH, Lambda
(3) SRLG
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
ASes.
6. Security consideration
Security consideration will be discussed in a future version. This
requirement will not change the underlying security issues.
7. 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.
8. Normative references
1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[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-
07.txt, June 2004 (work in progress).
T. Otani et al. Informational - Expires January 2005 8
Internet Drafts draft-otani-ccamp-interas-GMPLS-TE-00.txt July 2004
[LMP] J. Lang, et al, öLink Management Protocol (LMP)ö,
draft-ietf-lmp-10.txtö, October 2003.
[GMPLS-Routing] K. Kompera, et al, öRouting Extensions in Support of
Generalized Multi-Protocol Label Switchingö, draft-
ietf-ccamp-gmpls-routing-09.txt, October 2003.
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
Michiaki Hayashi
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7547
Saitama, 356-8502. Japan Email: mc-hayashi@kddilabs.jp
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
Document expiration
This document will be expired in January 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 9