Internet DRAFT - draft-demizu-udlr-dtcp
draft-demizu-udlr-dtcp
Network Working Group Noritoshi Demizu
Internet Draft SonyCSL, Inc.
Expiration Date: May 1998
Hidetaka Izumiyama
Japan Satellite Systems, Inc.
November 1997
Dynamic Tunnel Configuration Protocol
<draft-demizu-udlr-dtcp-00.txt>
Status of this memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
As the Internet grows, the importance of Uni-Directional Links such
as satellite links has been increasing. However, most of existing
routing protocols assume that datalinks are bi-directional. To
incorporate UDLs into the Internet, an IP tunneling approach has been
proposed, where tunnels are set up as a virtual back-channel of a UDL
to carry routing information between Feeders and Receivers.
Dynamic Tunnel Configuration Protocol (DTCP) supports to setup
tunnels dynamically between Feeders and Receivers in such
environments.
Demizu, Izumiyama [Page 1]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
1. Introduction
To use Uni-Directional Link (UDL) such as satellite links as an IP
route, an IP tunneling approach[1] has been prpoposed. In this
approach, tunnels are set up as a virtual back-channel of a UDL to
carry routing information between Feeders and Receivers. Some of
such UDLs might have only one Feeder, others might have more than
one.
Dynamic Tunnel Configuration Protocol (DTCP) supports to setup
tunnels dynamically between Feeders and Receivers in that
environments. The main roles of DTCP are:
- to notify the availability of the Feeder to Receivers.
- to exchange node information that is necessary to transfer packets
through a UDL (e.g. MAC addresses of Receivers to forward unicast
packets)
- to establish and to release tunnels dynamically, including dynamic
IP address allocation for Receivers if necessary.
Here is the outline of the procedure to start using a UDL as an IP
route with DTCP:
1. Feeders send a "DTCP Announcement" message to a UDL periodically.
2. When a Receiver hears this message and it wants to use the UDL,
it sends a "DTCP Request" message to a Feeder to establish a
tunnel between the Feeder and the Receiver. Receiver MAC
address is included in this message.
3. The Feeder sends back a "DTCP Reply" message to the Receiver to
notify of acceptance or rejection. If the Feeder accepts the
request, a tunnel is established between the Feeder and the
Receiver. A UDL IP address is dynamically allocated to the
Receiver, if it does not have a statically allocated UDL IP
address.
4. The Feeder and the Receiver exchange routing information over
the tunnel and the UDL to use the UDL as an IP route.
5. Packets start to go through the UDL.
As figured above, DTCP helps the procedure 1. through 3. The
procedure 4. and 5. are out of the scope of this document. Feeder
selection algorithm by Receivers for the case where multiple Feeders
exist on a UDL is also out of the scope of this document.
This document specifies the format and semantics of DTCP. Section 2
outlines how DTCP works in the environment of [1]. Section 3
specifies the DTCP format and the meanings of each field. Section 4
depicts DTCP state transition diagram. Section 5 recommends default
values of constants used in this document.
Demizu, Izumiyama [Page 2]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
2. The outline of DTCP
DTCP has four types of messages. These messages can be categorized
into following two:
1. DTCP Announcement message: "Announcement"
- This message is periodically sent from each Feeder to
Receivers to notify the avalability of the Feeder.
2. DTCP Tunnel Setup messages: "Request", "Reply", "Release"
- These messages are triggered by a DTCP Announcement message.
The aims of these messages are to establish and to release
tunnels dynamically.
In the environment of [1], there can be many Receivers per one
Feeder. To avoid that a flood of messages comes to a Feeder from
many Receivers at the same time, each node SHOULD obey the following
rules when sending messages:
1. DTCP Announcement message:
- A Feeder SHOULD send DTCP Announcement messages at the
interval rate as the Feeder specifies in the "interval"
field of DTCP Announcement messages. The interval rate
SHOULD be fixed during the Feeder keeps sending the
messages.
2. DTCP Tunnel Setup messages:
- A Receiver MUST wait for random seconds between 0 to
DTCP_ANN_WAIT before sending a message triggered by a DTCP
Announcement message.
- Only Receivers that are specified by the pattern field of a
trigger DTCP Announcement message can send a response
message. Other Recievers SHOULD NOT respond to the DTCP
Announcement message.
- When a Feeder is willing to send messages to all Receivers
that has a tunnel with the Feeder, the Feeder SHOULD wait
for random seconds between 0 to DTCP_ANN_WAIT before sending
a message to each Receiver.
- In other cases, any messages can be sent any time.
If a Receiver has not heard any DTCP Announcement message after its
boot, or if a Receiver does not hear DTCP Announcement messages for
more than DTCP_ANN_TIMEOUT from a Feeder, or when a Feeder does not
send a DTCP Announcement message periodically, a Receiver and a
Feeder SHOULD assume DTCP_ANN_INTERVAL as the announced interval
rate.
Since Feeders and Receivers can connect to multiple UDLs at the same
Demizu, Izumiyama [Page 3]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
time, UDL network addresses SHOULD be unique among those UDLs to
allow Feeders and Receivers to distinguish UDLs. That is, UDL
network address space SHOULD be either a part of global address space
or a part of private address space that are well coordinated among
UDL service providers so that UDL IP addresses are uniquely
allocated.
The following subsections describe DTCP messages. State names used
in these subsections are the one used in the state transition diagram
in Section 4.
2.1 DTCP Announcement Message
The DTCP Announcement Message is periodically sent from a Feeder to
Receivers through a UDL. The roles of a DTCP Announcement Message
are:
- to notify the availability of a Feeder to Receivers.
- to give a clock to Receivers to determine a timing to send a DTCP
Tunnel Setup message to the Feeder.
- to announce Feeder's information that is necessary to send a DTCP
Request message.
A Feeder SHOULD send DTCP Announcement messages periodically if the
Feeder is working and a UDL is administratively available. The
interval rate SHOULD be notified in the interval field of this
message. The recommended interval rate is DTCP_ANN_INTERVAL. The
code field of this message indicates the availability of the Feeder
and tunnels.
If the code field of a DTCP Announcement message received by a
Receiver is DTCP_CODE_OK, it means the Feeder is available and a new
tunnel can be set up with the Feeder. If the Receiver does not have
a tunnel yet and the Receiver wants to have one, the Receiver can set
up a tunnel by using Tunnel Setup messages (See 2.2). If the
Receiver already has a tunnel with the Feeder, the Receiver can keep
using the tunnel and the UDL. If the valid time of a tunnel with the
UDL is almost expired, the Receiver can request to extend the valid
time of the tunnel.
If the code field of a DTCP Announcement message received by a
Receiver is DTCP_CODE_FULL, it means the Feeder is available but a
new tunnel cannot be setup no more with the Feeder at the moment. If
the Receiver does not have a tunnel yet and the Receiver wants to set
up a tunnel, the Receiver SHOULD wait for another DTCP Announcement
message with code value DTCP_CODE_OK. If the Receiver already has a
tunnel with the Feeder, the Receiver can keep using the tunnel and
the UDL. If the valid time of a tunnel with the UDL is almost
Demizu, Izumiyama [Page 4]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
expired, the Receiver can request to extend the valid time of the
tunnel.
If the code field of a DTCP Announcement message received by a
Receiver is DTCP_CODE_GOINGDOWN, or the Receiver does not hear a DTCP
Announcement message from a Feeder for DTCP_ANN_TIMEOUT, it means the
Feeder is not available and tunnels should be released if the
Receiver has. If the Receiver wants to use the UDL, the Receiver
needs to establish a tunnel with other Feeder.
If the sequence field of a DTCP Announcement message received by a
Receiver changes more than expected, it means that the Feeder has
been booted without saving information of Recievers and tunnels. If
the Receiver wants to keep using UDL or to start to use UDL, the
Receiver needs to send a DTCP Tunnel Setup Request message to a
Feeder.
2.2. DTCP Tunnel Setup Messages
The DTCP Tunnel Setup messages consist of three messages: Request,
Reply, and Release. These messages are exchanged between a Feeder
and a Receiver through a BDL on demand. They have the same formats,
but op field has a different value for each message.
The roles of DTCP Tunnel Setup Messages are:
- to establish and to release a tunnel dynamically between a Feeder
and a Receiver. Recievere's UDL IP address can be allocated with
these messages in the case where the Receiver does not have a
statically allocated UDL IP address.
- to notify Receiver's node information that is necessary for
communication to a Feeder. (e.g. Receiver's MAC address)
The outline of the procedure follows. State names here are the state
transition diagram in Section 4.
0. A Receiver hears a DTCP Announcement message from a Feeder. (See 2.1)
Receiver's state becomes OPEN.
1. The Receiver sends a DTCP Request message to the Feeder.
Receiver's MAC address is carried on the DTCP options field if
necessary. Receiver's state becomes REQ_SENT. If Feeder
receives this message, Feeder's state for the Receiver becomes
REQ_RECV. A Feeder has a tunnel state per Receiver.
2. The Feeder sends back a DTCP Reply message to the Receiver.
If the request is accepted, the code field of the reply message
is DTCP_CODE_OK. The Feeder SHOULD configure the tunnel before
Demizu, Izumiyama [Page 5]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
sending back the message. After the Receiver prepares for the
tunnel, the tunnel can be used. Both Feeder's state and
Receiver's state become ESTABLISHED.
at a Feeder:
- To avoid a flood of request messages to extend the valid
time of tunnels from Receivers, the valid time assigned
to each Receiver SHOULD be varied between
DTCP_TUN_VALIDTIME plus-minus DTCP_TUN_REFRESH.
If the Feeder does not want assign such a long period,
the period can be shorten, but with random variation
(plus-minus DTCP_TUN_REFRESH). If the Receiver wants to
be assigned shorter period than DTCP_TUN_VALIDTIME, there
is no need of variation.
at a Receiver:
- The Receiver SHOULD use the dynamically allocated UDL IP
address if allocated.
- The Receiver can send routing information only when the
Receiver is allowed to do it.
If the Receiver receives a reply message with its code value
DTCP_CODE_NO, or the Receiver does not get any response from a
Feeder, the Receiver should wait for another DTCP Announcement
message with code value DTCP_CODE_OK. Both Feeder's state and
Receiver's state becomes OPEN.
3. If the rest of valid time becomes less than DTCP_TUN_REFRESH,
the Receiver sends a DTCP Request message to the Feeder to extend
the valid time. By this request, the Receiver can extend the
valid time of both a tunnel and the dynamically assigned UDL IP
address at the same time. All fields including DTCP options of
the DTCP Request message SHOULD be filled as if it is a request
message when the Receiver has a statically allocated UDL IP
address. Receiver's state becomes REFRESHING, but Feeder's state
does not change from ESTABLISHED.
The Feeder sends back a DTCP Reply message. All fields including
DTCP options of the DTCP Reply message SHOULD be filled as if it
is a reply message to a request that is to set up a new tunnel.
If the Receiver does not receive any reply message, the Receiver
SHOULD wait for another DTCP Announcement message with code value
DTCP_CODE_OK. If the code field of the reply message is
DTCP_CODE_NO, it means the Receiver cannot extend the valid time
of the tunnel. After the valid time is expired, both the Feeder
and the Receiver unconfigure the tunnel, and MUST NOT keep using
the tunnel.
If the request is accepted, Receiver's state becomes ESTABLISHED.
If the request is denied, Receiver's state becomes NOREFRESH.
Feeder's state does not change in either case.
Demizu, Izumiyama [Page 6]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
4. If a Receiver finishes using a tunnel, the Receiver sends a DTCP
release message to the Feeder to release the tunnel. Either
Feeder or Receiver can send a DTCP Release message first. The
tunnel between the Feeder and the Recever is released after the
exchange of DTCP Release messages between them.
- If a Receiver (or a Feeder) sends a DTCP Release message
first, its state becomes REL_WAIT. If the Receiver (or the
Feeder) does not receive a response release message, the
Receiver (or the Feeder) SHOULD send a DTCP Release message
again after a next DTCP Announcement message. After receiving
a response release message, its state becomes OPEN.
- If a Feeder (or a Receiver) receives a DTCP Release message
for an existing tunnel, the Feeder (or the Receiver) SHOULD
release the tunnel and send back a DTCP Release message.
Feeder's state becomes OPEN.
- If a Feeder or a Receiver receives a DTCP Release message
for an unknown tunnel, it SHOULD send back a DTCP Release
message for the unknown tunnel.
- If the releasing is successful, Both Feeder's state and
Receiver's state become OPEN.
3. The format of DTCP messages
DTCP is a protocol over UDP. Its port number is (TBD).
3.1. Announcement Message Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Op | Code | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence |Pattern Length | RecvID type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pattern |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feeder ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDL Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feeder BDL IP addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DTCP options... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
src IP addr of the IP header:
- Feeder's UDL IP address
dst IP addr of the IP header:
Demizu, Izumiyama [Page 7]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
- 255.255.255.255 (link-local broadcast address of IPv4)
dst port of the UDP header:
- (TBD)
Op:
0 = DTCP Announcement message
Code:
0 = DTCP_CODE_OK
This Feeder is active and new tunnels can be set up
with this Feeder.
1 = DTCP_CODE_FULL
This Feeder is active but new tunnels cannot be set
up with this Feeder. e.g. address pool is empty,
or a tunnel table is full.
2 = DTCP_CODE_GOINGDOWN
This Feeder will be down soon.
Interval:
- Interval time in second to send a DTCP Announcement
message. The recommended interval is DTCP_ANN_INTERVAL.
This field SHOULD not be changed during the Feeder
keeps sending DTCP Announcement messages.
Sequence:
- Sequence number of DTCP Announcemenet messages.
A Feeder SHOULD assign an initial random number when
it boots so that Receivers can recognize this Feeder'
rebooting from the big change of this field.
The next sequence number of 2^16-1 is 0.
Pattern:
- This field is to limit the number of Receivers that
can respond to a DTCP Announcemnet message to avoid
a flood of DTCP messages. Only Receivers who
satisfies following expression are allowed to respond.
(Reciever_ID) & MASK == pattern & MASK,
where MASK = (1 << Pattern_Length) - 1
- Unused pattern bits SHOULD be zero.
Pattern Length:
- See the explanation for pattern field.
RecvID type: (Receiver-ID type)
- See the explanation for pattern field.
0 = Receiver BDL IP address
1 = Receiver MAC address
Feeder ID:
- Identity information of the Feeder. This field will
be used to select a Feeder by Receivers. --(TBD)--
UDL Netmask:
- the netmask of the UDL
Feeder BDL IP addr:
- Feeder BDL IP address
Demizu, Izumiyama [Page 8]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
3.2. Request, Reply, Release Messages Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Op | Code | Valid Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Flags | Accept Flags | Tunnel Proto | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src UDL IP addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dst UDL IP addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DTCP options... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
src IP addr of the IP header:
- Source node's BDL IP address
dst IP addr of the IP header:
- Destination node's BDL IP address
dst port of the UDP header:
- Default port number is (TBD).
Op:
8 = Request
- To request to establish a tunnel, to extend
the valid time of a tunnel, or to change the
parameters sent before.
- Known information SHOULD be put into fields.
9 = Reply
- To respond to a request message.
- Known information SHOULD be put into fields.
10 = Release
- To release a tunnel.
Code:
- In a Request message, MUST be zero.
- In a Reply message,
0 = DTCP_CODE_OK
The request is Accepted.
1 = DTCP_CODE_FULL
The request is denied, because tunnel is
unavailable, e.g. the address pool is empty,
or tunnel table is full.
2 = DTCP_CODE_NO
The request is denied because of
administrative reasons.
- In a Release message, MUST be zero.
Valid Time:
- Valid time of a tunnel in second. If Receiver's
Demizu, Izumiyama [Page 9]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
UDL IP address is allocated dynamically, this field
also means its valid time.
- In a Request message, the source node puts a valid
time it wishes. Zero means source node does not
want to use tunnel no more. Zero would be used to
release tunnels gracefully.
- In a Reply message, the source node put a valid time
it allows. If the source node does not allow to use
a tunnel, this field MUST be zero. The source node
can tell longer period than the destination wishes,
especially when the destination wishes zero seconds.
- In a Release message, MUST be zero.
Request Flags: (Request flags from a source node)
Accept Flags: (Acceptable flags by a destination node)
- In a Release message, all bits MUST be zero.
- In a Request and a Reply message, each bit has
following meanings:
(R=Request Flags, A=AcceptFlags, MSB=7)
7: unicast routing info
- R: If source node wants to send unicast
routing information, then 1, else 0.
- A: If source node accepts unicast routing
information, then 1, else 0.
- If a node says 1 in R, and the opposite node
says 1 in A, then unicast routin information
can be sent in the direction.
6: multicast routing info
- R: If source node wants to send multicast
routing information, then 1, else 0.
- A: If source node accepts multicast routing
information, then 1, else 0
- If a node says 1 in R, and the opposite node
says 1 in A, then multicast routing information
can be sent in the direction.
5: IGMP (join, leave)
- R: If source node wants to send IGMP join/leave,
then 1, else 0.
- A: If source node accepts IGMP join/leave,
then 1, else 0.
- If a node says 1 in R, and the opposite node
says 1 in A, then IGMP join/leave can be
sent in the direction.
4: reserved: (MUST BE zero)
3: reserved: (MUST BE zero)
2: reserved: (MUST BE zero)
1: unnumbered or not
- R: If source node wants unnumbered tunnel,
Demizu, Izumiyama [Page 10]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
then 1, else 0.
- A: reserved (MUST BE zero)
- If both nodes say 1, then the tunnel is
unnumbered.
0: TTL treatment in a tunnel
- R: If source node wants TTL field to be
decremented by the number of hops, then 1.
If source node wants TTL field to be
decremented only by 1, then 0.
- A: reserved (MUST BE zero)
- If both nodes say 1, then TTL is decremented
by the number of hops.
- If a node wants to change flags, the node sends a
Request message.
Tunnel Proto (Tunneling Protocol):
- Selected tunneling protocol.
- In a request message, if a node can support multiple
tunneling protocol, this field SHOULD be zero and a
candidates list SHOULD be appeared in DTCP options.
If a node can support only one tunneling protocol,
this field is filled with the protocol.
- If the opposite node sends a tunneling protocol list
in a DTCP options of a request message, this field
of a reply message should be filled with the
selected protocol. If any of the protocols are not
supported, the request SHOULD be rejected and this
field MUST be zero.
Reserved:
- (MUST BE zero)
src UDL IP addr:
- Source node's UDL IP address
- If source node knows its UDL IP address, this field
SHOULD be filled with the address. For example,
a UDL IP address is statically allocated, or it has
been already allocated dynamically by a previous request.
- If source node does not know its UDL IP address,
this field MUST be zero. For example, in the case
where requesting a UDL IP address in a Request message.
dst UDL IP addr:
- Destination node's UDL IP address
- If source node knows destination's UDL IP address,
this field SHOULD be filled with the address.
- If source node does not know destination's UDL IP
address, this field MUST be zero. For example, in
Demizu, Izumiyama [Page 11]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
the case where notifying a failure of a tunnel setup
request by a Reply message.
DTCP options:
- All the options that was necessary to establish
tunnel SHOULD appear in all Request and Reply
messages. This would avoid troubles if opposite
side has been rebooted after last exchange of DTCP
messages.
3.3. DTCP options:
- No Operation
+-------+
| type |
+-------+
type: 0 = NoOp
- No Operation
+-------+-------+-------+-------+
| type | len | padding... |
+-------+-------+-------+-------+
type: 1 = NoOp, len = N
- padding MUST be zero.
- UDL Netmask
+-------+-------+
| type | len |
+-------+-------+-------+-------+
| UDL Netmask |
+-------+-------+-------+-------+
type: 2 = UDL Netmask, len = 6
- to notify UDL Netmask.
- Acceptable Tunneling Protocol option
+-------+-------+-------+-------+
| type | len |list of proto..|
+-------+-------+-------+-------+
type: 3 = acceptable tunnel proto, len = N
- To notify acceptable tunneling protocol. Protocols are
listed in the order of precedence.
- Each protocol is denoted by 1 byte.
- 1: ipproto=4 (IP in IP)
- 2: ipproto=94, raw packet format (IP within IP)
- Selected protocol is notified by using the tunnel protocol
field of DTCP Tunnel Setup messages.
Demizu, Izumiyama [Page 12]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
- Authentication option (Certification?)
+-------+-------+-------+-------+
| type | len | ........ |
+-------+-------+-------+-------+
type: 4 = authentication info, len = N
- (TBD)
- basic authentication
- otp
- etc.
- Source node's MAC address
+-------+-------+-------+-------+
| type | len | MAC(high) |
+-------+-------+-------+-------+
| MAC(low) |
+-------+-------+-------+-------+
type: 5 = src MAC addr, len = 8
- to notify source node's MAC address (or EUI-48).
- Typically, to notify Receiver's MAC address to a Feeder.
4. State Transition Diagram
State Transition Diagram for DTCP Tunnel Setup Messages:
(Event/Action style)
Demizu, Izumiyama [Page 13]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
+-------------+ ---+ REQ0/REL
| CLOSED | | REL/REL
+-------------+ <--+
A
|
V
+-------------+
+--------------------->| OPEN |<---------------------------+
| +-------------+ |
| / \ |
| / \ |
| /(Next+wait) \REQUEST/[C] |
| / /REQUEST \ |
| / \ |
|(LinkDown), v v |
|NO/ +-----------+ REQUEST/ +-----------+ |
+<----------| REQ_SENT |---------->| REQ_RECV | |
| +-----------+ +-----------+ |
| A | \ / |
| | V \ / |
| +---+ \ / |
| (Next+wait)/REQ \ / |
| \ / |
+-----------+ ---+(Next+wait) | | |
| REL_WAIT | |/REL |OK/ |/OK |
+-----------+ <--+ | | |
A | | RELEASE/RELEASE |[!T]
|[!T] |[T] |[T] +------------------------>+
| | | / |
|(LinkDown),REQ0, v v / |
|(EndOfComm)/RELEASE +-------------+ ---+ |
+<---------------------| ESTABLISHED | |REQUEST/OKorNO |
| +-------------+ <--+ |
| A | |
| |(VT>x), |(ValidTime<x&&cont)/REQUEST |
|(LinkDown),REQ0, |(!cont) |(stop) |
|(ValidTime==0), | v |
|(EndOfComm)/RELEASE +-------------+ ---+(Next+wait)/REQUEST |
+<---------------------| REFRESHING | |OK/ |
| +-------------+ <--+ |
| A | \ |
| |REQ/OK | \ RELEASE/RELEASE |
|(LinkDown),REQ0, |OK/ |NO/ +------------------------>+
|(ValidTime==0), | v |
|(EndOfComm)/RELEASE +-------------+ RELEASE/RELEASE |
+<---------------------| NOREFRESH |--------------------------->+
+-------------+
Demizu, Izumiyama [Page 14]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
Next: DTCP Announcemenet with DTCP_CODE_OK
wait: random wait
LinkDown: TimeOut or DTCP Announcement with DTCP_CODE_GOINGDOWN
[T]: Tunnel up
[!T]: Tunnel down
[C]: check whether the request is acceptable
5. Recommended constant values or expressions
DTCP_ANN_INTERVAL: 10 (sec)
- Interval time of sending DTCP Announcement messages
DTCP_ANN_WAIT: interval / 2 (5 sec by default)
- The maximum waiting time to respond after receiving a DTCP
Announcement message.
DTCP_ANN_TIMEOUT: interval * 6 (60 sec by default)
- The valid time of a DTCP Announcement message.
DTCP_TUN_VALIDTIME: 1200 (sec) (= interval * 120)
- Tunnel valid time.
DTCP_TUN_REFRESH: interval * 12 (120 sec by default)
- Threshold value to start extending tunnel valid time.
Security Considerations
Security issues are not discussed in this document.
Acknowledgements
The concept and the basic design of DTCP is a result of discussions
by the members of Wish-WG of WIDE Project. Noboru Fujii and Mikiyo
Nishida give members technical valuable input from their independent
experience of implementation. Hitoshi Asaeda, Akira Kato, Kazuhiro
Hara, Jun Takei, and Akihiro Tosaka give members technical valuable
comments.
References
[1] H. Izumiyama, A. Tosaka, A. Kato,
"An IP tunneling approach for Uni-directional Link routing",
<draft-ietf-udlr-wide-tunnel-00.txt>, Nov 1997
Demizu, Izumiyama [Page 15]
Internet Draft draft-demizu-udlr-dtcp-00.txt November 1997
[2] H. Izumiyama, A. Tosaka,
"Dynamic Tunneling Path Configuration for Uni-directional Link Routing",
<draft-ietf-udlr-dtpc-00.txt>, Nov 1997
Authors Information
Noritoshi Demizu
Sony Computer Science Laboratory, Inc.
Takanawa Muse Bldg.
3-14-13, Higashigotanda,
Shinagawa-ku, Tokyo, 141 Japan
Phone: +81-3-5448-4380
E-mail: demizu@csl.sony.co.jp
E-mail: nori-d@is.aist-nara.ac.jp
Hidetaka Izumiyama
Japan Satellite Systems Inc.
Toranomon 17 Mori Bldg.5F
1-26-5 Toranomon,
Minato-ku, Tokyo 105 Japan
Phone: +81-3-5511-7568
Fax: +81-3-5512-7181
E-mail: izu@jcsat.co.jp
Demizu, Izumiyama [Page 16]
