One document matched: draft-oki-ccamp-gtep-01.txt
Differences from draft-oki-ccamp-gtep-00.txt
CCAMP Working Group Eiji Oki (NTT)
Internet Draft Daisaku Shimazaki (NTT)
Expiration Date: April 2005 Kohei Shiomoto (NTT)
October 2004
Generalized Traffic Engineering Protocol
draft-oki-ccamp-gtep-01.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.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2004). 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.
E. Oki et al. [Page 1]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
Abstract
This draft describes a generalized traffic engineering protocol (GTEP).
GTEP is a protocol that communicates between a Path Computation Element
(PCE) and a GMPLS controller (GMPLS CNTL). A GMPLS CNTL is a controller that
handles GMPLS and MPLS protocols such as routing and signaling protocols
and controls a GMPLS node. PCE provides a function of traffic engineer-
ing, which calculates LSP routes and judges whether a new lower-layer
LSP should be established and whether an existing lower-layer LSP should
be released.
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
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to sup-
port various switching technologies. GMPLS enables us to control a
packet switching network, layer 2 switching networks such as asyn-
chronous transfer mode (ATM) and Ethernet, TDM networks such as syn-
chronous digital hierarchy/synchronous optical network (SDH/SONET),
lambda and fiber networks all at once.
A GMPLS-based multi-region network architecture is addressed in
[MRN_REQ][MRN_EXT]. Multi-region traffic engineering in GMPLS networks
increases network resource efficiency, because all the network resources
are taken into account at the same time. However, in GMPLS multi-region
network environments, traffic engineering becomes more complicated, com-
pared with that in single-region network environments. For example, let
us consider hierarchical label switched paths (LSPs) [LSP-HIERARCHY],
where a higher-layer LSP uses a lower-layer LSP as a TE-link. When the
higher-layer LSP is setup, it is necessary judged whether new lower-
layer LSPs SHOULD be established for forwarding adjacency LSPs (FA-
LSPs), or existing lower-layer LSPs SHOULD be used for FA-LSPs. It is
not realistic that the LSP route calculation engine, or path computation
element (PCE), that performs multi-region traffic engineering (MRTE)
with several constraints is implemented into all the node. Moreover,
judgements such as whether new LSPs SHOULD be established, or existing
LSPs SHOULD be used depends on network providers' traffic-engineering
policy. Network providers want to have own traffic engineering engine.
From vendors' points of view, it is not desirable to implement PCE that
considers all the requirements from network providers. A complicated PCE
E. Oki et al. [Page 2]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
may also cause the node to degrade its processing capability. There-
fore, it is reasonable to separate the PCE from a GMPLS controller that
handles GMPLS protocols.
This draft describes a generalized traffic engineering protocol (GTEP).
GTEP is a protocol that communicates between PCE and the GMPLS con-
troller (GMPLS CNTL).
2. GTEP Overview
2.1. GTEP Common Definitions
All GTEP packets are run over TCP with a GTEP port number The GTEP port
number is TBA (to be assigned) by IANA. For the time being, A private
port number, which is in the range between 49152 and 65535, is used.
+------------------+
| +------+ |
| |RSVP | |
| |module| |
+-----------+ | +------+ |
| PCE +---------||---------+ |
+-----------+ GTEP | +----+ +------+ |
| |LSDB+--+ OSPF | |
| +----+ |module| |
| +------+ |
+------------------+
GMPLS CNTL
Figure 1 Communication between PCE and GMPLS CNTL with GTEP.
GTEP is a protocol that communicates between PCE and a GMPLS CNTL. A
GMPLS CNTL is a controller that handles GMPLS and MPLS protocols and
controls a GMPLS node.
The GMPLS CNTL handles GMPLS protocols such as signaling and routing
protocols. Figure 1 depicts the GMPLS CNTL structure that includes a
RSVP module and a OSPF module with a Link State Database (LSDB)
PCE provides a function of traffic engineering, which calculates LSP
routes and judges whether a new lower-layer LSP SHOULD be established.
Applicability of PCE is as follows. For single-layer networks, PCE pro-
vides LSP routes considering several constraints. For multi-region net-
works, a function of multi-region traffic engineering, which calculates
LSP routes and judges whether a new lower-layer LSP SHOULD be
E. Oki et al. [Page 3]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
established.
The detail functions of the GMPLS CNTL and PCE based on GTEP are
described in the following subsections.
2.2. GMPLS CNTL Function
A GMPLS CNTL is a controller that handles GMPLS and MPLS protocols and
controls a GMPLS node. When the GMPLS CNTL tries to setup a new LSP, or
receives a Path message from the previous hop node, it requires the PCE
to give the LSP route to it. The PCE calculates the LSP route and gives
it to the GMPLS CNTL. The GMPLS CNTL establishes the LSP according to
the route suggested by the PCE.
The PCE requires the GMPLS CNTL to setup a lower-layer LSP if it is nec-
essary. In this case, the GMPLS CNTL tries to setup the lower-layer LSP
and returns the result whether the LSP setup succeeds to the PCE. When
the LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for the FA
LSP.
When a Link State Database (LSDB) in the GMPLS CNTL is updated, it sends
the updated LSDB information to the PCE. When the GMPLS CNTL is
requested to give the LSDB information, it sends the latest LSDB infor-
mation to the PCE.
2.3. PCE Function
PCE gives the GMPLS CNTL an LSP route when the LSP route is requested by
the GMPLS CNTL. The PCE calculates the LSP route by using Traffic Engi-
neering Database (TED). TED in the PCE is created by using the informa-
tion of the LSDB in the GMPLS CNTL.
The PCE requires the GMPLS CNTL to setup a lower-layer LSP if it is nec-
essary. In this case, the GMPLS CNTL tries to setup the lower-layer LSP
and returns the result whether the LSP setup succeeds to the PCE. When
the LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for a FA
LSP. The PCE creates a route of the requested higher-layer LSP by using
LSP_TUNNEL_IF_ID as interfaces of TE-links and send the route to the
GMPLS CNTL.
When a Link State Database (LSDB) in the GMPLS CNTL is updated, it sends
the updated LSDB information to the PCE. According to the LSDB update,
the PCE also updates the TED. When the PCE is booted, it requests the
information of LSDB to the GMPLS CNTL. The GMPLS CNTL sends the infor-
mation of LSDB to the PCE. Then, the PCE creates TED.
E. Oki et al. [Page 4]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
3. GTEP Procedure
3.1. PCE Boot Sequence
PCE GMPLS CNTL
| |
| ConfigRequest Message |
|-------------------------------->|
| |
| ConfigResponse Message |
|<--------------------------------|
| |
| LsRequest Message |
|-------------------------------->|
| |
| LsResponse Message |
|<--------------------------------|
| |
Figure 2 PCE boot sequence.
Step 1. The PCE is booted.
Step 2. The PCE sends ConfigRequest Message to the GMPLS CNTL to request
configuration in the GMPLS CNTL.
Step 3. The GMPLS CNTL sends ConfigResponse Message to the PCE to give
the configuration.
Step 4. The PCE sends LsRequest Message to the GMPLS CNTL to request the
LSDB information in the GMPLS CNTL.
Step 5. The GMPLS CNTL send LsResponse Message to the PCE to give the
LSDB information.
3.2. LSP Setup Sequence for Single Layer Case
PCE GMPLS CNTL
| |
| RouteRequest Message |
|<--------------------------------|
| |
| RouteResponse Message |
|-------------------------------->|
| |
Figure 3 LSP setup sequence for single layer case.
E. Oki et al. [Page 5]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
Step 1. The GMPLS CNTL is requested to setup an LSP.
Step 2. The GMPLS CNTL sends RouteRequest Message to the PCE to ask it
to give the LSP route.
Step 3. The PCE sends RouteResponse Message to the GMPLS CNTL to give
the LSP route.
3.3. LSP Setup Sequence for Two Layer Case
PCE GMPLS CNTL
| |
| RouteRequest Message |
|<--------------------------------|
| |
| LspSetupRequest Message* |
|-------------------------------->|
| |
| LspSetupResponse Message* |
|<--------------------------------|
| |
| RouteResponse Message |
|-------------------------------->|
| |
*The LspSetupRequest/LspSetupResponse Messages appear only when the
lower-layer LSP needs to be established.
Figure 4 LSP setup sequence for two layer case.
Step 1: The GMPLS CNTL is requested to setup an higher-layer LSP. The
node that is connected to the GMPLS CNTL MAY be an ingress node, or an
transit node from the high-layer LSP's point of view.
Step 2: If at least one condition in the following is satisfied, go to
Step 3. 1. In the case of an ingress node, Explicit Route is not speci-
fied. In the case of a transit node, Explicit Route Object is included
in a Path Message. 2. When Explicit Route is specified, the next hop
node is specified as Loose. 3. When Explicit Route is specified and the
next hop node is specified as "Strict", there is no TE-link that satis-
fies constraints such as bandwidth between the node and the next hop
node. Otherwise, go to Step 7.
Step 3. The GMPLS CNTL sends RouteRequest Message to the PCE to request
a route of the higher-layer LSP.
Step 4. The PCE requires the GMPLS CNTL to setup a lower-layer LSP if it
E. Oki et al. [Page 6]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
is necessary. Otherwise, go to Step 6.
Step 5. The GMPLS CNTL tries to setup the lower-layer LSP and returns
the result whether the LSP setup succeeds to the PCE. When the LSP setup
succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP.
Step 6. The PCE sends RouteResponse Message that specifies the route of
the higher-layer LSP to the GMPLS CNTL. The specified route is formatted
as Explicit Route Object that is carried in a Path message. Then, go to
Step 7.
Step 7. Signaling procedure starts as an ingress node, or continues as
an transit node for the higher-layer LSP, according to the route speci-
fied by Explicit Route Object.
3.4. LSP Setup initiated by PCE
PCE GMPLS CNTL
| |
| LspSetupRequest Message* |
|-------------------------------->|
| |
| LspSetupResponse Message* |
|<--------------------------------|
| |
Figure 5 LSP Setup initiated by PCE
Step 1. The PCE initiates to require the GMPLS CNTL to setup an LSP,
when the PCE determined that a new LSP setup is necessary. The initia-
tion is triggered by traffic demand change, network topology change, and
network failure.
Step 2. The GMPLS CNTL tries to setup the LSP and returns the result
whether the LSP setup succeeds to the PCE. When the LSP setup succeeds,
the result includes LSP_TUNNEL_IF_ID for the FA LSP.
3.5. LSP Release initiated by PCE
PCE GMPLS CNTL
| |
| LspReleaseRequest Message* |
|-------------------------------->|
| |
| LspReleaseResponse Message* |
|<--------------------------------|
E. Oki et al. [Page 7]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
| |
Figure 6 LSP Setup initiated by PCE
Step 1. The PCE initiates to require the GMPLS CNTL to release an exist-
ing LSP, when the PCE determined that the existing LSP setup is not nec-
essary. The initiation is triggered by traffic demand change, network
topology change, and network failure.
Step 2. The GMPLS CNTL tries to release the LSP and returns the result
whether the LSP release succeeds to the PCE.
4. GTEP Message
4.1. Common Header and Common Trailer
In addition to the TCP header and standard IP header, all GTEP messages
have the following common header and common trailer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | GTEP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Marker (32 bits, ASCII CODE "GTEP") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Common Header and Common Trailer
The Reserved field should be sent as zero and ignored on receipt. All
values are defined in network byte order (i.e., big-endian byte order).
Version: 8 bits. Protocol version number. This is version 1.
Message Type: 8 bits. The following values are defined.
1 = RouteRequest Message
2 = RouteResponse Message
3 = RouteRequestCancel Message
4 = LspSetupRequest Message
E. Oki et al. [Page 8]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
5 = LspSetupResponse Message
6 = LspReleaseRequest Message
7 = LspReleaseResponse Message
8 = LsUpdate Message
9 = LsRequest Message
10 = LsResponse Message
11 = ConfigRequest Message
12 = ConfigResponse Message
Result: 8 bits. A value of "NoSuccessAck" indicates that the request
message does not expect a response if the outcome is successful, and a
value of "AckAll" indicates that a response is expected if the outcome
is successful. In both cases a failure response MUST be generated if the
request fails. In a response message, the result field can have two val-
ues: "Success" and "Failure". The "Success" and "Failure" results indi-
cate success and failure responses, respectively. All messages that
belong to the same success response will have the same Transaction Iden-
tifier. The following values are defined.
1 = NoSuccessAck
2 = AckAll
3 = Success
4 = Failure
Code: 8 bits. Field gives further information concerning the result in a
response message. It is mostly used to pass an error code in a failure
response but can also be used to give further information in a success
response message or an event message. In a request message, the code
field is not used and is set to zero.
Transaction ID: 24 bits. Used to associate a request message with its
response message. For request messages, the controller may select any
transaction identifier. For response messages, the transaction identi-
fier is set to the value of the transaction identifier from the message
to which it is a response. For event messages, the transaction identi-
fier SHOULD be set to zero. The Transaction Identifier is not used, and
the field is not present, in the adjacency protocol.
GTEP Length: 16 bits. Length of the GTEP message including its header
fields, defined GTEP message body, and marker field. It is expressed by
byte.
Marker: 32 bits. This 32-bit filed contains ASCII CODE "GTEP". With the
maker field and the length, it is judged whether GTEP messages are cor-
rectly sent and received. If the marker field does not contain ASCII
CODE "GTEP", it indicates that the GTEP message has a format error. In
this case, the TCP connection is disconnected, and the CSPF, which is a
client, sets up the TCP connection with the GMPLS CNTL, which is a
E. Oki et al. [Page 9]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
server, again.
4.2. GTEP Message Format
GTEP messages are built using objects. Each object is identified by its
Object Class and Class-type. Each object has a name, which is always
capitalized in this document.
All values are defined in network byte order (i.e., big-endian byte
order). The format of the GTEP object is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class | C-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ (object contents) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 GTEP Object
Class: 8 bits. The Class indicates the object type. Each object has a
name, which is always capitalized in this document.
C-Type: 8 bits. Class-type, unique within an Object Class. Values are
defined in Section 5.
Length: 8 bits. Length of the GTEP object including its header fields
and defined GTEP object contents. It is expressed by byte.
4.2.1. RouteRequest Message
The RouteRequest message is used when the GMPLS CNTL requests the PCE to
give the GMPLS CNTL an LSP route. In the common header, the result is
set to 2 and the transaction ID is set to a non-zero value. The contents
of the RouteRequest message are built using GTEP objects. The format of
the RouteRequest message is as follows:
<RouteRequest Message> ::= <Common Header>
[<TIME_VALUE>]
<DESTINATION_IP_ADDRESS>
<LABEL_REQUEST>
<BANDWIDTH>
<PROTECDTION>
[<PRIMARY_PATH_ROUTE>]
E. Oki et al. [Page 10]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
[<SECONDARY_PATH_ROUTE>]
TIME_VALUE is an option and indicates an allowable waiting time from
when the RouteRequest message is sent to the PCE until when the RouteRe-
sponse message is received from the PCE. If TIME_VALUE is not included,
a default allowable waiting time configured by the GMPLS CNTL is used.
If the allowable waiting time expires before the RouteResponse message
is received, the waiting state is released.
DESTINATION_IP_ADDRESS indicates a destination IP address of the LSP
route that is requested to be calculated from the node connected to the
GMPLS CNTL. DESTINATION_IP_ADDRESS MAY NOT be the same as the destina-
tion address of the LSP. DESTINATION_IP_ADDRESS MAY be a router id of a
transit node. In a transit node, when an explicit route object in the
Path message includes "loose" for a part of the LSP route, the GMPLS
CNTL asks the PCE to give the exact route of the LSP that is specified
as "loose" by the explicit route in the Path message. On the other hand,
in the transit node, when an explicit route object strictly specifies
the next hop node but there is no direct TE-link to the next hop node
that satisfies the constraints, the GMPLS CNTL sends the RouteRequest
message to the PCE by setting DESTINATION_IP_ADDRESS as the next hop
node.
LABEL_REQUEST includes LSP encoding type, switching type, and informa-
tion on the LSP direction, which is uni-direction or bi-direction. By
using these values, the type of LSP that should be setup is described.
BANDWIDTH indicates the LSP bandwidth.
PROTECTION indicates the protection type of LSP that should be setup.
PRIMARY_PATH_ROUTE is an option. It is set when the GMPLS CNTL requests
the PCE for the route of the secondary LSP that is disjoint from the
primary LSP. SECONDARY_PATH_ROUTE is an option. It is set when the
GMPLS CNTL requests the PCE for the route of the secondary LSP.
4.2.2. RouteResponse Message
The RouteResponse message is used when the GMPLS CNTL gives the PCE an
LSP route that is requested by the PCE. In the common header, the result
is set to 3 (success) or 4 (failure), and the transaction ID is set to
the value that is set by the RouteRequest message. The contents of the
RouteResponse message are built using GTEP objects. The format of the
RouteResponse message is as follows:
<RouteResponse Message> ::= <Common Header>
[<PRIMARY_PATH_ROUTE>]
E. Oki et al. [Page 11]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
[<SECONDARY_PATH_ROUTE>]
When the result is set to 3 (success), the RouteResponse message
includes either <PRIMARY_PATH_ROUTE> or <SECONDARY_PATH_ROUTE>, or both
of them, according to the request of the RouteRequest message.
In the common header, when the result is set to 4 (failure), the code is
defined as follows:
Code = 1: Format error of RouteRequest message
Code = 2: Failure on the calculation for the requested LSP route.
4.2.3. RouteCancel Message
The RouteCancel message is used when the GMPLS CNTL cancels the request
that is sent to the PCE as the RouteRequest message. When the PCE
receives the RouteCancel message from the GMPLS CNTL, the CSPF stops the
LSP route calculation. In the common header,
the result is set to 1, and the transaction ID is set to the value that
is set by the RouteRequest message. The contents of the RouteCancel mes-
sage are built using GTEP objects. The format of the RouteCancel message
is as follows:
<RouteCancel Message> ::= <Common Header>
4.2.4. LspSetupRequest Message
The LspSetupRequest message is used when the PCE request the GMPLS CNTL
to setup the lower-layer LSP if it is necessary to setup the higher-
layer LSP, whose route is requested by the RouteRequest message. In the
common header, the result is set to 2, and the transaction ID is set to
a non-zero value. The contents of the LspSetupRequest message are built
using GTEP objects. The format of the LspSetupRequest message is as fol-
lows:
<LspSetupRequest Message> ::= <Common Header>
[<TIME_VALUE>]
<SOURCE_IP_ADDRESS>
<DESTINATION_IP_ADDRESS>
<LABEL_REQUEST>
<BANDWIDTH>
<PROTECTION>
<PRIMARY_PATH_ROUTE>
[<SECONDARY_PATH_ROUTE>]
E. Oki et al. [Page 12]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
TIME_VALUE is an option and indicates an allowable waiting time from
when the LspSetupRequest message is sent to the GMPLS CNTL until when
the LspSetupRequest message is receded from the GMPLS CNTL. If
TIME_VALUE is not included, a default allowable waiting time configured
by the PCE is used. If the allowable waiting time expires before the
LspSetupResponse message is received, the waiting state is released.
SOURCE_IP_ADDRESS indicates a source IP address of the LSP that is
requested to be setup. The node that is connected to the GMPLS node is
a source node. DESTINATION_IP_ADDRESS indicates a destination IP
address of the LSP that is requested to be setup.
LABEL_REQUEST includes LSP encoding type, switching type, and informa-
tion on the LSP direction, which is uni-direction or bi-direction. By
using these values, the type of LSP that should be setup is described.
BANDWIDTH indicates the LSP bandwidth. The GMPLS CNTL SHOULD setup the
LSP whose bandwidth is equal to or more than the value indicated by
BANDWIDTH.
PROTECTION indicates the protection type of LSP that should be setup.
PRIMARY_PATH_ROUTE is mandatary. It indicates the route of the primary
LSP. SECONDARY_PATH_ROUTE is an option. It is set when the PCE requests
the secondary LSP in addition to the primary LSP.
4.2.5. LspSetupResponse Message
The LspSetupResponse message is used when the GMPLS CNTL gives the PCE
the result of the LSP setup that is requested by the PCE. In the common
header, the result is set to 3 (success) or 4 (failure), and the trans-
action ID is set to the value that is set by the LspSetupRequest mes-
sage. The contents of the LspSetupResponse message are built using GTEP
objects. The format of the LspSetupResponse message is as follows:
<LspSetupResponse Message> ::= <Common Header>
<INGRESS_LSP_TUNNEL_IF_ID>
<EGRESS_LSP_TUNNEL_IF_ID>
When the result is set to 3 (success), the LspSetupResponse message
includes both INGRESS_LSP_TUNNEL_IF_ID and EGRESS_LSP_TUNNEL_IF_ID.
In the common header, when the result is set to 4 (failure), both
INGRESS_LSP_TUNNEL_IF_ID and EGRESS_LSP_TUNNEL_IF_ID are not included in
the LspSetupResponse Message and the code is defined as follows:
Code = 1: Format error of LspSetupRequest message
E. Oki et al. [Page 13]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
Code = 2: Failure on the requested LSP setup.
4.2.6. LspReleaseRequest Message
The LspReleaseRequest message is used when the PCE request the GMPLS
CNTL to release an existing LSP, when the PCE determined that the exist-
ing LSP setup is not necessary. The initiation is triggered by traffic
demand change, network topology change, and network failure. In the com-
mon header, the result is set to 2, and the transaction ID is set to a
non-zero value. The contents of the LspSetupRequest message are built
using GTEP objects. The format of the LspReleaseRequest message is as
follows:
<LspReleaseRequest Message> ::= <Common Header>
[<TIME_VALUE>]
<SOURCE_IP_ADDRESS>
<DESTINATION_IP_ADDRESS>
<INGRESS_LSP_TUNNEL_IF_ID>
<EGRESS_LSP_TUNNEL_IF_ID>
TIME_VALUE is an option and indicates an allowable waiting time from
when the LspReleaseRequest message is sent to the GMPLS CNTL until when
the LspReleaseRequest message is receded from the GMPLS CNTL. If
TIME_VALUE is not included, a default allowable waiting time configured
by the PCE is used. If the allowable waiting time expires before the
LspSetupResponse message is received, the waiting state is released.
SOURCE_IP_ADDRESS/DESTINATION_IP_ADDRESS indicates a source/destination
interface IP address of the LSP that is requested to be released if the
both-end FA addresses is numbered.
INGRESS_LSP_TUNNEL_IF_ID/EGRESS_IP_ADDRESS indicates a source/destina-
tion unnumbered address of the LSP that is requested to be released.
Either SOURCE_IP_ADDRESS/DESTINATION_IP_ADDRESS or INGRESS_LSP_TUN-
NEL_IF_ID/EGRESS_IP_ADDRESS is used.
4.2.7. LspReleaseResponse Message
The LspReleaseResponse message is used when the GMPLS CNTL gives the PCE
the result of the LSP release that is requested by the PCE. In the com-
mon header, the result is set to 3 (success) or 4 (failure), and the
transaction ID is set to the value that is set by the LspReleaseRequest
message. The contents of the LspReleaseResponse message are built using
GTEP objects. The format of the LspReleaseResponse message is as fol-
lows:
E. Oki et al. [Page 14]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
<LspReleaseResponse Message> ::= <Common Header>
The code is defined as follows:
Code = 1: Format error of LspSetupRequest message
Code = 2: Failure on the requested LSP setup.
4.2.8. LsUpdate Message
The LsUpdate message is used when the GMPLS CNTL sends the PCE the
updated LSAs. In the common header, the result is set to 1, and the
transaction ID is set to a non-zero value. The contents of the LsUpdate
message are built using GTEP objects. The format of the LsUpdate message
is as follows:
<LsUpdate Message> ::= <Common Header>
<LSA>
...
<LSA>
The GMPLS CNTL sends the PCE only the updated LSAs, which includes LSAs
that are written or deleted in the Link State Database (LSDB), with the
LsUpdate message. LSAs that are not changed in the LSDB SHOULD NOT be
sent to the PCE. The deleted LSA is recognized by the MaxAge. The LSA is
identified by the link state type, the link state ID, and the advertis-
ing router. The CSPF overwrites the updated LSA as a new LSA in the
database, if the updated LSA has the same values of the link state type,
the link state ID, and the advertising router in the database.
4.2.9. LsRequest Message
The LsRequest message is used when the PCE requests the GMPLS CNTL for
all the LSAs that the GMPLS CNTL has. In other words, the LsRequest mes-
sage is used when the PCE is booted, or the PCE's database has a problem
and its database needs to be refreshed.
In the common header, the result is set to 2, and the transaction ID is
set to a non-zero value. The contents of the LsRequest message are built
using GTEP objects. The format of the LsRequest message is as follows:
<LsRequest Message> ::= <Common Header>
[<TIME_VALUE>]
TIME_VALUE is an option and indicates an allowable waiting time from
when the LsRequest message is sent to the GMPLS CNTL until when the
LsResponse message is received from the GMPLS CNTL. If TIME_VALUE is
E. Oki et al. [Page 15]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
not included, a default allowable waiting time configured by the PCE is
used. If the allowable waiting time expires before the LsResponse mes-
sage is received, the waiting state is released.
4.2.10. LsResponse Message
The ConfigResponse message is used when the GMPLS CNTL sends the PCE its
configuration of the router. In the common header, the result is set to
3 (success) or 4 (failure), and the transaction ID is set to the value
that is set by the ConfigRequest message. The contents of the ConfigRe-
sponse message are built using GTEP objects. The format of the ConfigRe-
sponse message is as follows:
<LsResponse Message> ::= <Common Header>
<LSA>
...
<LSA>
When the result is set to 3 (success), the GMPLS CNTL sends the PCE all
the LSAs with the LsResponse. When the PCE received the LsResponse mes-
sage, the LSA data in the PCE is cleared if any, it writes the LSAs car-
ried by the LsResponse message in the PCE database.
In the common header, when the result is set to 4 (failure), both LSAs
are not included in the LsResponse Message and the code is defined as
follows:
Code = 1: Format error of LsRequest message
Code = 2: There is no LSA in the GMPLS CNTL.
4.2.11. ConfigRequest Message
The ConfigRequest message is used when the PCE requests the GMPLS CNTL
for the configuration of the router. In the common header, the result is
set to 2, and the transaction ID is set to a non-zero value. The con-
tents of the ConfigRequest message are built using GTEP objects. The
format of the ConfigRequest message is as follows:
<ConfigRequest Message> ::= <Common Header>
[<TIME_VALUE>]
TIME_VALUE is an option and indicates an allowable waiting time from
when the ConfigRequest message is sent to the GMPLS CNTL until when the
ConfigResponse message is received from the GMPLS CNTL. If TIME_VALUE
is not included, a default allowable waiting time configured by the PCE
is used. If the allowable waiting time expires before the ConfigResponse
E. Oki et al. [Page 16]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
message is received, the waiting state is released.
4.2.12. ConfigResponse Message
The ConfigResponse message is used when the GMPLS CNTL sends the PCE its
configuration of the router. In the common header, the result is set to
3 (success) or 4 (failure), and the transaction ID is set to the value
that is set by the ConfigRequest message. The contents of the ConfigRe-
sponse message are built using GTEP objects. The format of the ConfigRe-
sponse message is as follows:
<ConfigResponse Message> ::= <Common Header>
<ROUTER_ID>
When the result is set to 3 (success), the ConfigResponse message
includes ROUTER_ID.
In the common header, when the result is set to 4 (failure), ROUTER_ID
is not included in the ConfigResponse Message and the code is defined as
follows:
Code = 1: Format error of ConfigRequest message
Code = 2: Failure to get the router id.
5. GTEP Object
5.1. TIME_VALUE
Class=2.
The information carried in TIME_VALUE is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 TIME_VALUE
5.1.1. C-type=1.
Time Value: 32 bits. The time value indicates an allowable waiting time
from when the request message is sent at the PCE/GMPLS CNTL until when
E. Oki et al. [Page 17]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
the LspSetupRequest message is received at the PCE/GMPLS CNTL. It is
expressed by millisecond.
5.2. SOURCE_IP_ADDRESS
Class=3.
The information carried in SOURCE_IP_ADDRESS is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address/Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 SOURCE_IP_ADDRESS
5.3. DESTINATION_IP_ADDRESS
Class=4.
The information carried in DESTINATION_IP_ADDRESS is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address/Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 DESTINATION_IP_ADDRESS
5.3.1. C-type=1.
Destination IPv4 address: 32 bits. The destination IPv4 address is the
destination of the requested route, which is an interface or a router
ID. The destination IPv4 address MAY NOT be the LSP destination, when a
part of the LSP route is requested.
5.4. LABEL_REQUEST
Class=5.
The information carried in LABEL_REQUEST is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
E. Oki et al. [Page 18]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | GIPD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 LABEL_REQUEST
5.4.1. C-type=1.
LABEL_REQUEST includes LSP encoding type, switching type, and informa-
tion on the LSP direction, which is uni-direction or bi-direction.
LSP Encoding Type: 8 bits. See [RFC3471] for a description of parame-
ters.
Switching Type: 8 bits. See [RFC3471] for a description of parameters.
GPID: 16 bits. See [RFC3471] for a description of parameters.
D: 1 bit. 0 indicates a uni-directional LSP. 1 indicates a bi-direc-
tional LSP.
5.5. BANDWIDTH
Class=6.
The information carried in BANDWIDTH is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 BANDWIDTH
5.5.1. C-type=1.
Bandwidth: 32 bits. The bandwidth indicates the required bandwidth.
Bandwidth encodings are carried in 32 bit number in IEEE floating point
format (the unit is bytes per second). See [RFC3471] for a definition of
values to be used for specific signal types.
E. Oki et al. [Page 19]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
5.6. PROTECTION
Class=7.
The information carried in PROTECTION is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |RT | Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: Reserved
RT: Route Type
Figure 14 PROTECTION
5.6.1. C-type=1.
Route Type: 4 bits.
0: The route of the primary LSP is requested.
1: The route of the secondary LSP is requested.
2: The routes of the primary and secondary LSPs are requested.
3: This value MUST NOT be used. A format error occurs if it is used.
When Route Type=0, SECONDARY_PATH_ROUTE MUST be included in the
RouteRequest message. When Route Type=1, PRIMARY_PATH_ROUTE MUST be
included in the RouteRequest message. When Route Type=2, PRI-
MARY_PATH_ROUTE and SECONDARY_PATH_ROUTE MUST NOT be included in the
RouteRequest message.
Other values is the same definition as those described in [GMPLS_RECOV-
ERY_E2E].
5.7. PATH_ROUTE
Class=8.
PATH_ROUTE consists of one or more Path route subobjects.
The information carried in PRTH_ROUTE is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Path route subobjects ~
E. Oki et al. [Page 20]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15 PATH_ROUTE
5.7.1. C-type=1, PRIMARY_PATH_ROUTE.
It indicates the primary route. It uses the following formats, which are
IPv4 numbered subobject and unnumbered subobject.
The information carried in IPv4 numbered subobject is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 IPv4 numbered subobject
L: 1 bit. 0 indicates the strict hop. 1 indicates the loose hop.
Type: 7 bits. 0x01: An IPv4 address, which is either numbered interface
address or Router ID, is specified.
Length: 8 bits. Length of all the IPv4 numbered subobject. It is
expressed by byte. The value is always set to 8.
The information carried in unnumbered subobject is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17 Unnumbered subobject
L: 1 bit. 0 indicates the strict hop. 1 indicates the loose hop.
Type: 7 bits. 0x04: Unnumbered address.
Length: 8 bits. It indicates the length of all the unnumbered subobject.
E. Oki et al. [Page 21]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
It is expressed by byte. The value is always set to 12.
5.7.2. C-type=2, SECONDARY_PATH_ROUTE.
It indicates the secondary route. It uses the same format as PRI-
MARY_PATH_ROUTE.
5.8. LSP_TUNNEL_IF_ID
Class=9.
5.8.1. C-type=1, INGRESS_LSP_TUNNEL_IF_ID.
It indicates the TUNNEL_IF_ID of the setup LSP at the ingress.
The information carried in LSP_TUNNEL_IF_ID is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18 LSP_TUNNEL_IF_ID
The format is based on TUNNEL_IF_ID described in [RFC3477]. See
[RFC3477] for a description of parameters.
5.8.2. C-type=2, EGRESS_LSP_TUNNEL_IF_ID.
It indicates the TUNNEL_IF_ID of the setup LSP at the egress. It uses
the same format as INGRESS_LSP_TUNNEL_IF_ID.
5.9. LSA
Class=10.
The information carried in LSA is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E. Oki et al. [Page 22]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| LSA contents |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19 LSA
5.9.1. C-type=1.
LSA includes all the LSA types.
Area ID: 32 bits. It indicates the area ID of the LSA.
Other values is the same definition as those described in
[RFC2328][RFC2370], except for the LS checksum and the length. The PCE
ignores the LS checksum. It indicates the length including 20 bytes LSA
header, except for the area ID, and the LSA contents. It is expressed by
byte.
5.10. ROUTER_ID
Class=11.
The information carried in ROUTER_ID is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20 ROUTER_ID
E. Oki et al. [Page 23]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
5.10.1. C-type=1.
Router ID: 32 bits. It indicates the route ID.
6. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any Intel-
lectual Property Rights or other rights that might be claimed to pertain
to the implementation or use of the technology described in this docu-
ment or the extent to which any license under such rights might or might
not be available; nor does it represent that it has made any independent
effort to identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assur-
ances 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 propri-
etary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this stan-
dard. Please address the information to the IETF at ietf-ipr@ietf.org.
7. 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.
8. References
[RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional
Description," RFC 3471 , Jan. 2003.
[RFC3473] P. Ashwood-Smith et al, "Generalized MPLS Signaling - RSVP-TE
Extensions," RFC 3473, Jan. 2003.
[RFC2338] J. Moy, "OSPF Version 2," RFC 2328.
[RFC2370] R. Coltun, "The OSPF Opaque LSA Option," RFC 2370.
[RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to OSPF
E. Oki et al. [Page 24]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
Version 2," RFC 3630.
[GMPLS_OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS," IETF draft, draft-ietf-ccamp-ospf-gmpls-exten-
sions-09.txt, Dec. 2002. (working in progress)
[GMPLS_RECOVERY_E2E] J.P. Lang et al., "RSVP-TE Extensions in support of
End-to-End GMPLS-based Recovery," IETF draft, draft-ietf-ccamp-gmpls-
recovery-e2e-signaling-00.txt, Mar. 2004. (working in progress)
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC 3477.
(working in progress)
[MRN_REQ] K. Shiomoto et al, "Requirements for GMPLS-based multi-region
and multi-layer networks," IETF draft, draft-shiomoto-ccamp-gmpls-mrn-
reqs-00.txt, Oct. 2004. (work in progress)
[MRN_EXT] D. Papadimitriou et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Protocol Extensions for Multi-Region Networks (MRN),"
IETF draft, draft-papadimitriou-ccamp-gmpls-mrn-extensions-00.txt, Oct.
2004. (work in progress)
[LSP-HIERARCHY] K. Kompella and Y. Rekhter, "LSP Hierarchy with General-
ized MPLS TE," draft-ietf-mpls-lsp-hierarchy-08.txt, Sep. 2002. (working
in progress)
9. Authors' Address
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
Daisaku Shimazaki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp
E. Oki et al. [Page 25]
E. Oki et al. draft-oki-ccamp-gtep-01.txt October 2004
E. Oki et al. [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-23 20:06:39 |