One document matched: draft-shore-ntlp-00.txt
Internet Draft Melinda Shore
draft-shore-ntlp-00.txt Cisco Systems
May 2003
Expires November 2003
The NSIS Transport Layer Protocol (NTLP)
<draft-shore-ntlp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 docu-
ments 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
The RSVP [RFC2205] model for communicating requests to network
devices along a datapath has proven useful for a variety of appli-
cations beyond what the protocol designers envisioned, and while
the architectural model generalizes well the protocol itself has a
number of features that limit its applicability to applications
other than IntServ [RFC1633]. The NSIS working group is developing
a modernized version that, among other things, is based on a "two-
layer" architecture that divides protocol function into transport
and application. This document describes the transport protocol.
1. Terminology
Generator
Shore [Page 1]
Internet Draft NTLP May 2003
NSLP
Path-coupled signaling
Receiver
Reservation
Sender
2. Introduction
RSVP is based on an "path-coupled" signaling model, in which sig-
naling messages between two endpoints follow a path that is tied to
the data path between the same endpoints, and in which the signal-
ing messages are intercepted and interpreted by RSVP-capable
routers along the path. While RSVP was originally designed to sup-
port QoS signaling for Integrated Services [RFC1633], this model
has proven to generalize to other problems extremely well. Some of
these problems include topology discovery, QoS signaling, communi-
cating with firewalls and NATs, discovery of IPSec tunnel end-
points, test applications, and so on.
The IETF's NSIS working group has been chartered to develop an
updated version of RSVP [Hancock, Brunner] -- one that is not tied
directly to IntServ and in which the protocol machinery itself is
sufficiently generalized to be able to support a variety of appli-
cations. What this means in practice is that there will be differ-
ent NSIS applications, all of which share a base NSIS transport
protocol. This is similar to the concepts used in secsh, where
authentication and connection protocols run on top of a secsh
transport protocol (see [Ylonen] for details).
[Hancock] describes the NSIS architectural framework. The protocol
machinery is based heavily on RSVP [RFC2205] with refresh overhead
reduction extensions [RFC2961].
NTLP differs from RSVP in several important ways, in addition to
the mandatory support for RFC 2961. One of the most significant of
these is that NTLP does not itself trigger reservations in NSIS
nodes. The NSIS application will do that, and, indeed, some NSIS
applications may not carry reservation requests at all (discovery
protocols, for example). Because of this NSIS does not support
reservation styles (those would be also be attributes of an appli-
cation). Another significant difference is that that reservations
may be installed by an NSLP in either a forward (from the sender
Shore [Page 2]
Internet Draft NTLP May 2003
toward the receiver) or backward (from the receiver toward the
sender) direction -- this is application-specific.
3. NTLP Messages
3.1. Message Processing Overview
Unlike RSVP, NTLP has only one fundamental message type. Direc-
tionality remains significant, but it is indicated through the use
of a "direction" flag and directionally-linked differences in mes-
sage processing may be inferred from the flag.
Even so, the basic operation of the protocol is similar to RSVP. A
message is injected into a network by the sender towards a receiver
with the receiver's address in the destination address in the IP
header. NSIS entities along the path the message traverses will
intercept it, store path state, act on (or not) the application
payload data, and forward the message towards its destination. In
NTLP, "path state" refers specifically to the unicast IP address of
the previous hop node.
When the message arrives at the receiver (or its proxy), the
receiver originates another NTLP message in response, with the
directionality flag set to indicate that the message is being sent
from the receiver to the sender. The primary difference in message
handling is that this message is routed hop-by-hop between the NSIS
nodes that handled the message in the forward direction. That is
to say that the destination address in the IP header is the address
of the next NSIS entity along the route in the reverse direction.
Path state that was collected in the forward direction is used to
accomplish this.
3.2. NTLP Message Format
NTLP messages consist of an NTLP header followed by optional TLV
fields followed by an NSLP payload.
3.2.1. The NTLP Header
All NTLP messages (and by implication, all NSIS messages) start
with an NTLP header. The header is formatted as follows:
Shore [Page 3]
Internet Draft NTLP May 2003
0 1 2 3
+-------------+-------------+-------------+-------------+
| Version | Flags | Message Length |
+-------------+-------------+-------------+-------------+
| TTL | (Reserved) | Checksum |
+-------------+-------------+-------------+-------------+
| Flow ID |
+-------------+-------------+-------------+-------------+
where the fields are as follows:
Version:
8 bits. The protocol version number; in this case 0x01.
Flags:
8 bits. Flag bits include
0x01 directionality 0x02 teardown
Message Length:
16 bits. The total number of octets in the message, including
the NTLP header and complete payload.
TTL: 8 bits. The IP TTL value with which the message was sent.
Checksum:
16 bits. The one's complement of the one's complement sum of
the entire message. The checksum field is set to zero for the
purpose of computing the checksum. This may optionally be set
to all zeros. If a message is received in which this field is
all zeros, no checksum was sent.
Flow ID:
32 bits. This is what is described as "Flow Identification"
in [Hancock]. It is a value which, combined with the source
IP address of the message, provides unique identification of a
message, which may be used for later reference for actions
such as quick teardowns, status queries, etc. The mechanism
used for generating the value is implementation-specific.
3.2.2. NTLP TLVs
NTLP carries additional transport-layer information and requests as
type-length-value fields, which are inserted after the header and
before the NSLP payload. The TLV format is as follows:
Shore [Page 4]
Internet Draft NTLP May 2003
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length | Type |
+-------------+-------------+-------------+-------------+
| |
// Value //
| |
+-------------+-------------+-------------+-------------+
where the fields are as follows:
Length:
16 bits. Total TLV length in octets. It must always be at
least 4 and be a multiple of 4.
Type:
16 bits. The type of information or request. Defined below.
Value:
Variable length -- at least 4 octets and a multiple of 4
octets). The TLV semantic content.
3.2.2.1. IPv4_HOP
+-------------+-------------+-------------+-------------+
| IPv4 Hop Address |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
The IPv4_HOP TLV carries the IPv4 address of the interface through
which the last NSIS entity forwarded the message. The logical
interface handle may be used to distinguish between multiple inter-
faces on the same entity, or it may be set to all 0s.
3.2.2.2. IPv6_HOP
Shore [Page 5]
Internet Draft NTLP May 2003
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Logical Interface Handle |
+-------------+-------------+-------------+-------------+
The IPv6_HOP TLV carries the IPv6 address of the interface through
which the last NSIS entity forwarded the message. The logical
interface handle may be used to distinguish between multiple inter-
faces on the same entity, or it may be set to all 0s.
3.2.2.3. IPv4_ERROR_CODE
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 octets) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The IPv4_ERROR_CODE TLV carries the address of a node at which an
NTLP error occurred, along with an error code and error value.
IPv4 Error Node Address:
4 octets. The IPv4 address of the interface on the node that
generated the error.
Flags:
8 bits. None currently defined.
Error Code:
Error Value:
3.2.2.4. IPv6_ERROR_CODE
Shore [Page 6]
Internet Draft NTLP May 2003
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Error Node Address (16 octets) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The IPv6_ERROR_CODE TLV carries the address of a node at which an
NTLP error occurred, along with an error code and error value.
IPv6 Error Node Address:
16 octets. The IPv6 address of the interface on the node that
generated the error.
Flags:
8 bits. None currently defined.
Error Code:
Error Value:
3.2.2.5. MESSAGE_ID
The MESSAGE_ID TLV is used to support reliable message delivery.
This, as well as the MESSAGE_ID_ACK and MESSAGE_ID_NACK TLVs, were
copied from RFC 2961.
The format is as follows:
+-------------+-------------+-------------+-------------+
| Flags | Epoch |
+-------------+-------------+-------------+-------------+
| Message_Identifier |
+-------------+-------------+-------------+-------------+
Flags: 8 bits
0x01 = ACK_Desired flag
Shore [Page 7]
Internet Draft NTLP May 2003
Indicates that the sender requests the reciever to send an
acknowledgment for the message.
Epoch: 24 bits
A value that indicates when the Message_Identifier sequence
has reset. SHOULD be randomly generated each time a node
reboots or the RSVP agent is restarted. The value SHOULD NOT
be the same as was used when the node was last operational.
This value MUST NOT be changed during normal operation.
Message_identifier: 32 bits
When combined with the message generator's IP address, the
Message_Identifier field uniquely identifies a message. The
values placed in this field change incrementally and only
decrease when the Epoch changes or when the value wraps.
Note that this field is not redundant with the Flow ID in the
NTLP header. The MESSAGE_ID TLV may be local between nodes,
rather than end-to-end. The Flow ID is an end-to-end identi-
fier.
3.2.2.6. MESSAGE_ID_ACK and MESSAGE_ID_NACK
These TLVs are also used to support reliable operations, and MES-
SAGE_ID_NACK is used to support summary refreshes.
The MESSAGE_ID_ACK format is as follows:
+-------------+-------------+-------------+-------------+
| Flags | Epoch |
+-------------+-------------+-------------+-------------+
| Message_Identifier |
+-------------+-------------+-------------+-------------+
Flags: 8 bits
No flags are currently defined. This field MUST be zero on
transmission and ignored on receipt.
Epoch: 24 bits
The Epoch field copied from the message being acknowledged.
Shore [Page 8]
Internet Draft NTLP May 2003
Message_Identifier: 32 bits
The Message_Identifier field copied from the message being
acknowledged.
The format of the MESSAGE_ID_NACK TLV is identical to the for-
mat of the MESSAGE_ID_ACK TLV.
3.2.2.7. TIME_VALUES TLV
+-------------+-------------+-------------+-------------+
| Refresh Period R |
+-------------+-------------+-------------+-------------+
The TIME_VALUES TLV carries the refresh timeout period R, in mil-
liseconds, used to generate the message in which this TLV appears.
This TLV is used only in RFC 2205-style messaging and state mainte-
nance.
3.2.2.8. MESSAGE_ID_LIST TLV
0 1 2 3
+-------------+-------------+-------------+-------------+
| Flags | Epoch |
+-------------+-------------+-------------+-------------+
| Message_Identifier |
+-------------+-------------+-------------+-------------+
| : |
// : //
| : |
+-------------+-------------+-------------+-------------+
| Message_Identifier |
+-------------+-------------+-------------+-------------+
Flags: 8 bits
No flags are currently defined. This field must be zero on
transmission and ignored on receipt.
Epoch: 24 bits
The Epoch field from the MESSAGE_ID TLV corresponding to the
trigger message that advertised the state being refreshed.
Message_Identifier: 32 bits
The Message_Identifier field from the MESSAGE_ID TLV corre-
sponding to the trigger message that advertised the state
being refreshed. One or more Message_Identifiers may be
Shore [Page 9]
Internet Draft NTLP May 2003
included.
4. Sending NTLP Messages
NTLP messages are sent as raw IP datagrams with protocol number
<xx>, or may optionally be encapsulated in UDP packets.
When an endhost or its proxy wishes to initiate an NTLP session, it
creates an NTLP message with the "directionality" bit in the NTLP
header set to 0. The destination address in the IP header is the
address that is expected to terminate the path along which signal-
ing is expected to be sent. It may be a application peer host or
terminal, or it may be a proxy.
NTLP messages should be sent with the router alert bit set in IPv4
headers or with the IPv6 router alert option [RFC2711].
In this version of the protocol, each NTLP message must fit in one
IP datagram. [we need text discussing fragmentation here - ed]
5. Messaging and State Maintenance
NTLP supports both RFC 2205-style messaging and RFC 2961-style mes-
sage for state installation and maintenance. RFC 2205 messaging is
used by default. Features from RFC 2961 may be used individually
with the indication of their use being feature-dependent.
5.1. RSVP v1 (RFC 2205)
RSVP takes a "soft state" approach to state maintenance in routers
and hosts, as described in [RFC2205]. State is installed and kept
fresh by periodically sending a full representation of installed
state in idempotent Path and Resv messages, and is deleted if no
matching Path/Resv refresh messages arrive before the timeout
period expires. State may also be deleted through the use of an
explicit teardown message.
5.1.1. Path Messages
When a host or its proxy wishes to initiate an NTLP session, it
generates a Path message and periodically retransmits it. The Path
message is addressed to a terminating host or its proxy. For exam-
ple, if the NSLP is making a QoS reservation for a particular data
flow, the Path message would be sent from the originator of a data
flow and addressed to the host to whom the data will be sent. The
source address in the IP header must be the address of the
Shore [Page 10]
Internet Draft NTLP May 2003
interface from which the message was originated.
The Path message must begin with an NTLP header and include a HOP
TLV. Other TLVs may be included, including for security purposes.
Note that the presence of some TLVs, such as the MESSAGE_ID TLV,
may indicate reliable message processing rather than RFC 2205-style
messaging. The directionality flag in the NTLP header flags field
must be set to 0x0.
The HOP TLV of each Path message contains the IP address of the
interface through which the Path message was most recently sent
(i.e. on the previous NSIS node). It may optionally carry a logi-
cal interface handle as well. Each NSIS-capable node along the
path captures the Path message and processes it to create path
state. Specifically, it stores the address and interface from the
HOP TLV and overwrites it with its own address. Additionally, it
will pass the NSLP payload to the appropriate NSLP module for pro-
cessing [for efficiency purposes, should we have a flag that says
not to do this in a particular direction? - ed]. Note that it does
not modify the source or destination addresses in the IP header.
5.1.2. Resv Messages
Resv messages carry requests from the receiver towards the sender.
Unlike Path messages, Resv messages are explicitly addressed to
NSIS nodes along the data path using the addresses discovered and
conveyed in the HOP fields in the precedent Path message. The
source address in the IP header is the address of the interface on
the NSIS node (i.e. not the "receiver") which sent the message.
The directionality flat in the NTLP header flags field must be set
to 0x1.
Unlike RFC 2205, instead of using a RESV_CONFIRM object we use the
reliable messaging extensions from RFC 2961, described below.
5.1.3. Path Teardown Messages
Receipt of a teardown message indicates that matching path state
must be deleted. A teardown message is one in which the teardown
bit is set in the NTLP header. Note that this is independent of
directionality, and the teardown message may be sent in either
direction. The applications which have reservations that were
installed by a message containing a matching Flow ID must be noti-
fied.
Shore [Page 11]
Internet Draft NTLP May 2003
Unlike RFC 2205, if there is no matching path state the teardown
message must be forwarded. There may be path state in support of
an NSIS application that is not running on every node, and the
teardown message must not be lost.
5.1.4. Timers
NTLP messages may contain a TIME_VALUES TLV describing the refresh
period (R) between state refresh messages. This value is also used
to derive the local state's lifetime value when the message is
received and processed. The use of the TIME_VALUES TLV is dis-
cussed in section 3.7 of RFC 2205.
5.2. RFC 2961
In order to reduce the amount of network traffic associated with
RSVP soft state maintenance, RFC 2961 specifies RSVP extensions for
refresh reduction. It also addresses reliability and latency prob-
lems stemming from message loss (increasing the interval between
refresh messages reduces the amount of state maintenance traffic on
the wire but increases the latency in response to routing changes
and increases the effects of dropped messages).
RFC 2961 reduces state maintenance traffic on the wire using sev-
eral mechanisms. One is to allow "bundling" of requests. Another
is the use of "summary" refresh messages, which obviates the need
to send entire refresh messages.
NTLP supports RFC 2961 message processing, and because of that the
"Refresh reduction capable" bit in the Flags field of the NTLP
header is redundant and therefore unnecessary. Similarly, in NTLP
all messages may carry multiple NSLP payloads and it is not neces-
sary to separately identify a "bundled" message type. Unlike RFC
2961, bundled messages may be carried end-to-end and the router
alert option/bit should be set. An NSIS node has the option of
unbundling bundled messages into multiple messages (because of a
smaller MTU on the outgoing link, for example, or to reduce trans-
mission latency of high-priority requests) or bundling multiple
NTLP messages into a single NTLP message.
5.3. MESSAGE_ID Usage
The MESSAGE_ID TLV may be included in any NTLP message other than
an ACK. It MUST NOT be used in a message that includes more than
one NSLP payload, which means that when an NSIS node wishes to
receive an ACK for a particular message, and that message has more
Shore [Page 12]
Internet Draft NTLP May 2003
than one NSLP payload, it must unbundle the NSLP payloads and
transmit the ones requiring acknowledgment individually. [let's
think about doing this in bundled messages - ed]
In messages containing a HOP TLV, the generator of the MESSAGE_ID
TLV appears in the HOP. If there is no HOP, it is taken from the
source address in the IP header.
The Epoch field contains a value selected by the generator. The
value is used to indicate when the sender resets the values used in
the Message_Identifier field. On startup, a node should randomly
select a value to be used in the Epoch field. It should ensure
that the selected value is not the same as was used when the node
was last operational. The value must not be changed unless the
node or agent is restarted.
The Message_Identifier field contains a generator-selected value.
This value, when combined with the generator's IP address, identi-
fies a particular NTLP message and the specific state information
it represents. When a node is sending a refresh message with a
MESSAGE_ID TLV, it should use the same Message_Identifier value
that was used in the NTLP message that identified the NSLP state
being refreshed. When a node is sending a trigger, the Mes-
sage_Identifier value must have a value that is greater than any
other Message_Identifier value previously used with the same Epoch
field value (note that this provides a way to determine if messages
are being delivered out-of-order). A value is considered to have
been used when it has been sent in any message using the associated
IP address with the same Epoch field value.
The ACK_Desired flag is set when the MESSAGE_ID generator wants an
acknowledgement with a MESSAGE_ID_ACK TLV in response. Such infor-
mation can be used to ensure reliable delivery of RSVP messages in
the face of network loss. Nodes setting the ACK_Desierd flag
should retransmite unacknowledged messages at a more rapid interval
than the standard refresh period until the message is acknowledged
or until the "rapid" retry limit is reached. Rapid retransmission
rate must be based on the exponential back-off procedures defined
below. The ACK_Desired flag will typically be set only in trigger
messages. The ACK_Desired flag may be set in a refresh message.
Nodes processing incoming MESSAGE_ID TLVs should check to see if a
newly-received message is out-of-order. Out-of-order messages
should be ignored. To determine ordering, the received Epoch value
must match the value previously received from the message genera-
tor. If the values differ the receiver must not treat the message
Shore [Page 13]
Internet Draft NTLP May 2003
as out of order. When the Epoch values match and the Message_Iden-
tifier value is less than the largest value previously received
from the sender, then the NSLP processor for the application pay-
load should check for existing state for that payload. If none
exists, the receiver must not treat the message as out of order.
If local state does exist, the message should be treated as out of
order.
Note that the Message_Identifier value may wrap. To cover the wrap
case, the following expression may be used to test if a newly
received Message_Identifier value is less than a previously
received value:
if ((int) old_id - (int) new_id > 0) {
new value is less than old value;
}
MESSAGE_ID TLVs of messages that are not out of order should be
used to aid in determining if the message represents new state or a
state refresh. Note that this refers only to NTLP state -- NSLP
application state is determined by the NSLP layer.
If the received Epoch value differs from the value previously
received, the message is a trigger message and the receiver must
fully process the message. If the message contains the same Mes-
sage_Identifier value that was used in the most recently received
message for the same session, then the receiver should treat the
message as a state refresh. If the Message_Identifier value is
greater than the most recently received value, then the receiver
must fully process the message. Note these guidelines will apply
to NSLP payloads in addition to NTLP state.
Nodes receiving a message that is not out-of-order containing a
MESSAGE_ID TLV with the ACK_Desired flag set should respond with a
MESSAGE_ID_ACK TLV. MESSAGE_ID TLVs received in messages contain-
ing errors (for example, not syntactically valid) must not be
acknowledged.
5.4. MESSAGE_ID_ACK and MESSAGE_ID_NACK Usage
The MESSAGE_ID_ACK TLV is used to acknowledge receipt of messages
containing MESSAGE_ID TLVs that were sent with the ACK_Desired flag
set. A MESSAGE_ID_ACK object must not be generated in response to
a received MESSAGE_ID TLV when the ACK_Desired flag is not set.
Shore [Page 14]
Internet Draft NTLP May 2003
The MESSAGE_ID_NACK object is used as part of the summary refresh
function. The generation and processing of MESSAGE_ID_NACK is
described in further detail below.
MESSAGE_ID_NACK and MESSAGE_ID_NACK TLVs may be sent in any NTLP
message that has an IP destination address matching the generator
of the associated MESSAGE_ID. This means that they will not typi-
cally be included in non hop-by-hop messages. When no appropriate
message is available, one or more ACKs or NACKs should be sent on
their own.
Implementation should limit the amount of time that an acknowledg-
ment is delayed in order to be piggy-backed or sent on its own.
Different limits may be used for MESSAGE_ID_ACK and MES-
SAGE_ID_NACK. MESSAGE_ID_ACK is used to detect link transmission
losses. If an ACK object is delayed too long, the corresponding
message will be retransmitted. To avoid retransmission, ACKs
should be delayed a minimal amount of time. A delay time equal to
the link transit time may be used. MESSAGE_ID_NACK may be delayed
an independent andlonger time, although additional delay increases
the amount of time a message is not acted upon.
5.5. Summary Refreshes
Summary refreshes enable the refreshing of NTLP and NSLP state
without the transmission of entire reservation request messages.
The benefits are that it reduces the amount of information that
must be transmitted and processed in order to maintain state syn-
chronization. Importantly, it preserves NTLP's ability to handle
non-NSIS next hops and to adjust to changes in routing.
The summary refresh mechanism builds on MESSAGE_ID. Only state
that was previously advertised in applications encapsulated in NTLP
messages containing MESSAGE_ID TLVs can be refreshed via a summary
refresh.
The summary refresh uses the TLVs and the ACK message previously
defined as part of the MESSAGE_ID functionality, and a new TLV that
is specifically in support of summary refresh. This TLV is the
MESSAGE_ID_ LIST.
The MESSAGE_ID_LIST TLV is used to refresh all NTLP and NSLP reser-
vation state and path-related state. It is made up of a list of
Message_Identifier fields that were originally advertised in MES-
SAGE_ID TLVs. An NTLP node receiving a message with a MES-
SAGE_ID_LIST TLV matches each listed Message_Identifier field with
Shore [Page 15]
Internet Draft NTLP May 2003
installed NTLP state, and requests the associated NSLP to do the
same. If matching state cannot be found then the sender is noti-
fied with a refresh NACK. A refresh NACK is sent via the MES-
SAGE_ID_NACK TLV. As described previously, the rules for sending a
MESSAGE_ID_NACK are the same as for sending a MESSAGE_ID_ACK. This
includes sending MESSAGE_ID_NACKs piggy-backed in an unrelated NTLP
message or in NTLP ACK messages.
5.5.1. MESSAGE_ID_LIST usage
Unlike RFC 2961, no special message format is used. If a MES-
SAGE_ID_LIST TLV appears in an NTLP message, the message is pro-
cessed according to procedures described above. Messages contain-
ing the MESSAGE_ID_LIST TLV are normally sent end-to-end in a for-
ward direction with a destination IP address equal to the address
of the original reservation, or trigger, request. The destination
IP address may be set to the NTLP next hop when the next hop is
known to be NTLP-capable.
The source IP address in a message containing a MESSAGE_ID_LIST TLV
is the address of the node that generated the message. The source
IP address must mach the address associated with the MESSAGE_ID
TLVs when they were included in a standard NTLP message. The
source address associated with a MESSAGE_ID depends on the contents
of the message. For messages with a HOP TLV, the address is found
in the HOP object. For other messages, the address is taken from
the source address in the IP header.
Only one MESSAGE_ID_LIST TLV is allowed per NTLP message.
5.5.2. Summary Refresh Message Processing
A MESSAGE_ID_LIST TLV may be used to refresh reservation and path
state. If summary refresh is used, the generation of a standard
refresh message should be suppressed. A state's refresh interval
is not affected by the use of summary refresh.
When generating summary refreshes, a node should refresh as much
state as possible by including the information from as many MES-
SAGE_ID TLVs as possible in the same MESSAGE_ID_LIST. Only the
information from MESSAGE_ID objects that describe the source and
destination IP address restrictions, as described above, may be
included in the same MESSAGE_ID_LIST.
Only state that was previously advertised in NTLP messages contain-
ing MESSAGE_ID TLVs can be refreshed using summary refresh. The
Shore [Page 16]
Internet Draft NTLP May 2003
use of summary refreshes must not result in state being timed out
at the NTLP next hop. The period at which state is refreshed using
summary refresh may be shorter than the period that would be used
using normal idempotent messaging, but it must not be longer.
The particular approach used to trigger summary refreshes is imple-
mentation specific. Some possibilities are based on each state's
refresh period, or on a per-interface basis.
When generating a summary refresh, there are two methods for iden-
tifying which path state may be refreshed in a specific message.
In both cases the previously mentioned refresh interval and source
IP address restrictions must be followed. The primary method is to
include only those sessions which share the same destination IP
address in the same MESSAGE_ID_LIST TLV.
The secondary, multicast-based method described in RFC 2961 is not
supported.
5.5.3. Summary Refresh NACKs
NACKs are used to indicate that a received Message_Identifier field
carried in a MESSAGE_ID_LIST does not match any installed state.
This may occur for a humber of reasons including, for example, a
route change. A summary refresh NACK is encoded in a MES-
SAGE_ID_NACK TLV. When generating a summary refresh NACK, the
Epoch and Message_Identifier fields of the the MESSAGE_ID_NACK must
have the same value as was received.
Received MESSAGE_ID_NACK TLVs indicate that the TLV generator does
not have any installed state matching the Message_Identifier
included in TLV. Upon recieving a MESSAGE_ID_NACK, the receiver
performs a lookup on uninstalled state based on the Epoch and Mes-
sage_Identifier values contained in the TLV. If matching state is
found then the receiver must transmit the matching state via a
standard forward or backward NTLP message. If the receiver cannot
identify any isntalled state, then no action is required.
5.5.4. Preserving Soft State
In RFC 2961, summary refreshes are used in place of the periodic
sending of full representations of installed state. While this
provides scaling benefits and protects against common network
events such as packet loss or routing changes, it does not provide
exactly the same error recovery properties. An example error that
could potentially be recovered from via standard messages but not
Shore [Page 17]
Internet Draft NTLP May 2003
with summary refresh is internal corruption of state. This section
recommends two methods that can be used to better preserve NTLP's
soft state error recovery mechanism. Both use existing protocol
messages.
The first uses a checksum or other algorithm to detect a previously
unnoticed change in internal state. This mechanism does not pro-
tect against internal state corruption. It just covers the case
where a trigger message should have been sent, but was not. When
sending a message, a node should run a checksum or MAC over the
internal state and store the result. The choice of algorithm is an
administrative decision. Periodically it should rerun the algo-
rithm and compare the new result with the stored result; if the
values differ, than a corresponding standard, full message should
be sent and the new value should be stored. The recomputationpe-
riod should be set based on the computational resources of the node
and the reliability requirements of the network.
The second mechanism is to periodically send full, standard NTLP
with complete NSLP payloads as appropriate. Since this mechanism
uses standard refresh mechanisms it can recover from the same
errors as NTLP without summary refresh. When doing this, the
period that standard refresh messages should are sent must be
longer than the interval between summary refresh messages in order
to gain the benefits of summary refresh. When sending a standard
refresh a corresponding summary refresh should not be sent during
the same refresh period. The frequency of generation of standard
refresh messages relative to summary refresh messages should be
configurable by the network administrator.
5.5.5. Exponential Back-off Procedures
This section is taken from RFC 2961 and is based on [Pan]. Imple-
mentations must use the described procedures or the equivalent.
5.5.5.1. Outline of Operation
The following is one possible mechanism for exponential back-off
retransmission of an unacknowledged NTLP message. When sending
such a message a node inserts a MESSAGE_ID TLV with the ACK_Desired
flag set. The sending node will retransmit the message until a
message acknowledgment is received or the message has been trans-
mitted a maximum number of times. Upon reception, a receiving node
acknowledges the arrival of the message by sending back a message
acknowledgment (one containing a corresponding MESSAGE_ID_ACK
TLV). When the sending node receives the acknowledgment,
Shore [Page 18]
Internet Draft NTLP May 2003
retransmission of the message is stopped. The interval between
retransmission is governed by a rapid retransmission timer. The
rapid retransmission timer starts at a small interval and increases
exponentially until it reaches a threshold.
5.5.5.2. Time parameters
The described procedures make use of the following time parameters.
All parameters are per-interface.
Rapid retransmission interval Rf:
Rf is the initial retransmission interval for unacknowledged
messages. After sending the message for the first time, the
sending node will schedule a retransmission after Rf seconds.
The value of Rf could be as small as the round trip time (RTT)
between a sending and receiving node, if known.
Rapid retry limit Rl:
Rl is the maximum number of times a message will be transmit-
ted without being acknowledged.
Increment value Delta:
Delta governs the speed with which the sender increases the
retransmission interval. The ratio of two successive retrans-
mission intervals is (1 + Delta).
Suggested default values are an initial retransmission timeout (Rf)
of 500ms, a power of 2 exponential back-off (Delta = 1), and a
retry limit (Rl) of 3.
5.5.5.3. Retransmission Algorithm
After a sending node transmits a message containing a MESSAGE_ID
TLV with the ACK_Desired flag set, it should immediately schedule a
retransmission after Rf seconds. If a corresponding MESSAGE_ID_ACK
TLV is received earlier than Rf seconds, then retransmission should
be canceled. Otherwise, it will retransmit the message after (1 +
Delta) * Rf seconds. The staged retransmission will continue until
either an appropriate MESSAGE_ID_ACK TLV is received, or the rapid
retry limit, Rl, has been reached.
A sending node can use the following algorithm when transmitting a
message containing a MESSAGE_ID TLV with the ACK_Desired flag set:
Prior to initial transmission initialize: Rk = Rf and Rn = 0
Shore [Page 19]
Internet Draft NTLP May 2003
while (Rn++ < Rl) {
transmit the message;
wake up after Rk seconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged or no reply from receiver for too long: */ do any
needed clean up; exit;
6. NSLP Interface
7. NAT Interactions
NTLP uses IP addresses for routing, both end-to-end and hop-by-hop.
Given the applications which NTLP will be transporting, it is
highly likely that those applications will be using payload-embed-
ded addresses and there will be some interactions. The use of a
NAT NSLP together with other NSLPs can mitigate this, but there
will be problems transiting non-NSIS-capable NATs.
When an NSIS entity receives an NTLP message travelling in the for-
ward direction, it writes the address in the IPv4_HOP or IPv6_HOP,
as appropriate, from the packet into local per-session state and
replaces the HOP data in the message with the address of the outgo-
ing interface. When the entity is a NAT, it will write the trans-
lated-to address. Note that while it is usually the case that pay-
load integrity protection breaks in the presence of NATs if embed-
ded addresses are being rewritten, this is not substantially dif-
ferent from the rewriting of the HOP field which occurs within NTLP
anyway.
However, if an NTLP message crosses a non-NSIS-capable NAT, several
problems may occur. The first is that if the message is being
dropped in a raw IP packet, the NAT may simply drop the packet
because it doesn't know how to treat it. Another is that the
address in the HOP field will be incorrect. NTLP and the applica-
tions it carries cannot be expected to function properly across
non-participating NATs.
8. Proxy Considerations
9. Security Considerations
[we need to determine exactly what we're protecting and why - ed].
Shore [Page 20]
Internet Draft NTLP May 2003
10. IANA Considerations
Protocol number
UDP port number
TLVs
11. Multicast Considerations
12. Acknowledgments
Large sections of this document were lifted wholesale from RFC
2961, and credit belongs with its authors: Lou Berger, Der-Hwa Gan,
George Swallow, Ping Pan, Franco Tommasi, and Simone Molendini.
13. Normative References
[Brunner] Brunner, M. "Requirements for Signaling Protocols," work
in progress, draft-ietf-nsis-req-08.txt, June 2003.
[Hancock] Hancock, R. et al. "Next Steps in Signaling: Framework,"
work in progress, draft-ietf-nsis-fw-02.txt, March 2003.
[Pan] Pan, P. and H. Schulzrinne. "Staged Refresh Timers for
RSVP," Global Internet '97, Phoenix, AZ, November 1997.
http://www.cs.columbia.edu/~pingpan/papers/timergi.pdf
[RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification," RFC 2205, September
1997. [RFC2711] Partridge, C. and A. Jackson. "IPv6 Router
Alert Option," RFC 2711, October 1999.
[RFC2961] Berger, L. et al. "RSVP Refresh Overhead Reduction
Extensions," RFC 2961, April 2001.
14. Informative References
[RFC1633] Braden, R., Clark, D., and S. Shenker. "Integrated Ser-
vices in the Internet Architecture," RFC 1633, June 1994.
[Ylonen] Ylonen, T. et al. "SSH Protocol Architecture," work in
progress, September 2002.
15. Author's Address
Melinda Shore
Cisco Systems
Shore [Page 21]
Internet Draft NTLP May 2003
809 Hayts Road
Ithaca, NY 14850
USA
mshore@cisco.com
16. TO DO
need better Flow ID - minimize collision likelihood
error codes
proxy issues, inc. early proxy terminating path
nslp headers
Should message_id be folded into the ntlp header?
timer object
MESSAGE_ID_NACK processing
Maybe directionality bit should be hop-by-hop bit?
fragmentation
security
IANA considerations
fill in terminology (definitions)
multicast considerations
simple example NSLP (discovery?)
17. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, pub-
lished and distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and this para-
graph are included on all such copies and derivative works. How-
ever, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the proce-
dures for copyrights defined in the Internet Standards process must
be followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI-
NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
Shore [Page 22]
Internet Draft NTLP May 2003
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR-
RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Shore [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 09:08:15 |