RFC 3209
RSVP-TE: Extensions to RSVP for LSP Tunnels
Pages: 61
Proposed Standard
→ Errata
Updated by: 3936 4420 4874 5151 5420 5711 6780 6790 7274
Proposed Standard
→ Errata
Updated by: 3936 4420 4874 5151 5420 5711 6780 6790 7274
Part 3 of 3 – Pages 43 to 61
4.7. Session Attribute Object
The Session Attribute Class is 207. Two C_Types are defined, LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The LSP_TUNNEL_RA C-Type includes all the same fields as the LSP_TUNNEL C-Type. Additionally it carries resource affinity information. The formats are as follows:4.7.1. Format without resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Session Name (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Setup Priority The priority of the session with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session. Holding Priority The priority of the session with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session.
Flags
0x01 Local protection desired
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
Name Length
The length of the display string before padding, in bytes.
Session Name
A null padded string of characters.
4.7.2. Format with resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclude-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-all | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Session Name (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Exclude-any A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link unacceptable. Include-any A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes. Include-all A 32-bit vector representing a set of attribute filters associated with a tunnel all of which must be present for a link to be acceptable (with respect to this test). A null set (all bits set to zero) automatically passes. Setup Priority The priority of the session with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session.
Holding Priority
The priority of the session with respect to holding resources,
in the range of 0 to 7. The value 0 is the highest priority.
Holding Priority is used in deciding whether this session can
be preempted by another session.
Flags
0x01 Local protection desired
This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit
route object. When a fault is detected on an adjacent
downstream link or node, a transit router can reroute
traffic for fast service restoration.
0x02 Label recording desired
This flag indicates that label information should be
included when doing a route record.
0x04 SE Style desired
This flag indicates that the tunnel ingress node may
choose to reroute this tunnel without tearing it down.
A tunnel egress node SHOULD use the SE Style when
responding with a Resv message.
Name Length
The length of the display string before padding, in bytes.
Session Name
A null padded string of characters.
4.7.3. Procedures applying to both C-Types
The support of setup and holding priorities is OPTIONAL. A node can
recognize this information but be unable to perform the requested
operation. The node SHOULD pass the information downstream
unchanged.
As noted above, preemption is implemented by two priorities. The
Setup Priority is the priority for taking resources. The Holding
Priority is the priority for holding a resource. Specifically, the
Holding Priority is the priority at which resources assigned to this session will be reserved. The Setup Priority SHOULD never be higher than the Holding Priority for a given session. The setup and holding priorities are directly analogous to the preemption and defending priorities as defined in [9]. While the interaction of these two objects is ultimately a matter of policy, the following default interaction is RECOMMENDED. When both objects are present, the preemption priority policy element is used. A mapping between the priority spaces is defined as follows. A session attribute priority S is mapped to a preemption priority P by the formula P = 2^(14-2S). The reverse mapping is shown in the following table. Preemption Priority Session Attribute Priority 0 - 3 7 4 - 15 6 16 - 63 5 64 - 255 4 256 - 1023 3 1024 - 4095 2 4096 - 16383 1 16384 - 65535 0 When a new Path message is considered for admission, the bandwidth requested is compared with the bandwidth available at the priority specified in the Setup Priority. If the requested bandwidth is not available a PathErr message is returned with an Error Code of 01, Admission Control Failure, and an Error Value of 0x0002. The first 0 in the Error Value indicates a globally defined subcode and is not informational. The 002 indicates "requested bandwidth unavailable". If the requested bandwidth is less than the unused bandwidth then processing is complete. If the requested bandwidth is available, but is in use by lower priority sessions, then lower priority sessions (beginning with the lowest priority) MAY be preempted to free the necessary bandwidth. When preemption is supported, each preempted reservation triggers a TC_Preempt() upcall to local clients, passing a subcode that indicates the reason. A ResvErr and/or PathErr with the code "Policy Control failure" SHOULD be sent toward the downstream receivers and upstream senders.
The support of local-protection is OPTIONAL. A node may recognize the local-protection Flag but may be unable to perform the requested operation. In this case, the node SHOULD pass the information downstream unchanged. The recording of the Label subobject in the ROUTE_RECORD object is controlled by the label-recording-desired flag in the SESSION_ATTRIBUTE object. Since the Label subobject is not needed for all applications, it is not automatically recorded. The flag allows applications to request this only when needed. The contents of the Session Name field are a string, typically of display-able characters. The Length MUST always be a multiple of 4 and MUST be at least 8. For an object length that is not a multiple of 4, the object is padded with trailing NULL characters. The Name Length field contains the actual string length.4.7.4. Resource Affinity Procedures
Resource classes and resource class affinities are described in [3]. In this document we use the briefer term resource affinities for the latter term. Resource classes can be associated with links and advertised in routing protocols. Resource class affinities are used by RSVP in two ways. In order to be validated a link MUST pass the three tests below. If the test fails a PathErr with the code "policy control failure" SHOULD be sent. When a new reservation is considered for admission over a strict node in an ERO, a node MAY validate the resource affinities with the resource classes of that link. When a node is choosing links in order to extend a loose node of an ERO, the node MUST validate the resource classes of those links against the resource affinities. If no acceptable links can be found to extend the ERO, the node SHOULD send a PathErr message with an error code of "Routing Problem" and an error value of "no route available toward destination". In order to be validated a link MUST pass the following three tests. To precisely describe the tests use the definitions in the object description above. We also define Link-attr A 32-bit vector representing attributes associated with a link.
The three tests are
1. Exclude-any
This test excludes a link from consideration if the link
carries any of the attributes in the set.
(link-attr & exclude-any) == 0
2. Include-any
This test accepts a link if the link carries any of the
attributes in the set.
(include-any == 0) | ((link-attr & include-any) != 0)
3. Include-all
This test accepts a link only if the link carries all of the
attributes in the set.
(include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0)
For a link to be acceptable, all three tests MUST pass. If the test
fails, the node SHOULD send a PathErr message with an error code of
"Routing Problem" and an error value of "no route available toward
destination".
If a Path message contains multiple SESSION_ATTRIBUTE objects, only
the first SESSION_ATTRIBUTE object is meaningful. Subsequent
SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.
All RSVP routers, whether they support the SESSION_ATTRIBUTE object
or not, SHALL forward the object unmodified. The presence of non-
RSVP routers anywhere between senders and receivers has no impact on
this object.
5. Hello Extension
The RSVP Hello extension enables RSVP nodes to detect when a
neighboring node is not reachable. The mechanism provides node to
node failure detection. When such a failure is detected it is
handled much the same as a link layer communication failure. This
mechanism is intended to be used when notification of link layer
failures is not available and unnumbered links are not used, or when
the failure detection mechanisms provided by the link layer are not
sufficient for timely node failure detection.
It should be noted that node failure detection is not the same as a link failure detection mechanism, particularly in the case of multiple parallel unnumbered links. The Hello extension is specifically designed so that one side can use the mechanism while the other side does not. Neighbor failure detection may be initiated at any time. This includes when neighbors first learn about each other, or just when neighbors are sharing Resv or Path state. The Hello extension is composed of a Hello message, a HELLO REQUEST object and a HELLO ACK object. Hello processing between two neighbors supports independent selection of, typically configured, failure detection intervals. Each neighbor can autonomously issue HELLO REQUEST objects. Each request is answered by an acknowledgment. Hello Messages also contain enough information so that one neighbor can suppress issuing hello requests and still perform neighbor failure detection. A Hello message may be included as a sub-message within a bundle message. Neighbor failure detection is accomplished by collecting and storing a neighbor's "instance" value. If a change in value is seen or if the neighbor is not properly reporting the locally advertised value, then the neighbor is presumed to have reset. When a neighbor's value is seen to change or when communication is lost with a neighbor, then the instance value advertised to that neighbor is also changed. The HELLO objects provide a mechanism for polling for and providing an instance value. A poll request also includes the sender's instance value. This allows the receiver of a poll to optionally treat the poll as an implicit poll response. This optional handling is an optimization that can reduce the total number of polls and responses processed by a pair of neighbors. In all cases, when both sides support the optimization the result will be only one set of polls and responses per failure detection interval. Depending on selected intervals, the same benefit can occur even when only one neighbor supports the optimization.5.1. Hello Message Format
Hello Messages are always sent between two RSVP neighbors. The IP source address is the IP address of the sending node. The IP destination address is the IP address of the neighbor node. The HELLO mechanism is intended for use between immediate neighbors. When HELLO messages are being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be set to 1.
The Hello message has a Msg Type of 20. The Hello message format is
as follows:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
5.2. HELLO Object formats
The HELLO Class is 22. There are two C_Types defined.
5.2.1. HELLO REQUEST object
Class = HELLO Class, C_Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2. HELLO ACK object
Class = HELLO Class, C_Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src_Instance: 32 bits
a 32 bit value that represents the sender's instance. The
advertiser maintains a per neighbor representation/value. This
value MUST change when the sender is reset, when the node reboots,
or when communication is lost to the neighboring node and
otherwise remains the same. This field MUST NOT be set to zero
(0).
Dst_Instance: 32 bits
The most recently received Src_Instance value received from the
neighbor. This field MUST be set to zero (0) when no value has
ever been seen from the neighbor.
5.3. Hello Message Usage
The Hello Message is completely OPTIONAL. All messages may be ignored by nodes which do not wish to participate in Hello message processing. The balance of this section is written assuming that the receiver as well as the sender is participating. In particular, the use of MUST and SHOULD with respect to the receiver applies only to a node that supports Hello message processing. A node periodically generates a Hello message containing a HELLO REQUEST object for each neighbor who's status is being tracked. The periodicity is governed by the hello_interval. This value MAY be configured on a per neighbor basis. The default value is 5 ms. When generating a message containing a HELLO REQUEST object, the sender fills in the Src_Instance field with a value representing it's per neighbor instance. This value MUST NOT change while the agent is exchanging Hellos with the corresponding neighbor. The sender also fills in the Dst_Instance field with the Src_Instance value most recently received from the neighbor. For reference, call this variable Neighbor_Src_Instance. If no value has ever been received from the neighbor or this node considers communication to the neighbor to have been lost, the Neighbor_Src_Instance is set to zero (0). The generation of a message SHOULD be suppressed when a HELLO REQUEST object was received from the destination node within the prior hello_interval interval. On receipt of a message containing a HELLO REQUEST object, the receiver MUST generate a Hello message containing a HELLO ACK object. The receiver SHOULD also verify that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously received value. If the Neighbor_Src_Instance value is zero, and the Src_Instance field is non-zero, the Neighbor_Src_Instance is updated with the new value. If the value differs or the Src_Instance field is zero, then the node MUST treat the neighbor as if communication has been lost. The receiver of a HELLO REQUEST object SHOULD also verify that the neighbor is reflecting back the receiver's Instance value. This is done by comparing the received Dst_Instance field with the Src_Instance field value most recently transmitted to that neighbor. If the neighbor continues to advertise a wrong non-zero value after a configured number of intervals, then the node MUST treat the neighbor as if communication has been lost. On receipt of a message containing a HELLO ACK object, the receiver MUST verify that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously
received value. If the Neighbor_Src_Instance value is zero, and the Src_Instance field is non-zero, the Neighbor_Src_Instance is updated with the new value. If the value differs or the Src_Instance field is zero, then the node MUST treat the neighbor as if communication has been lost. The receiver of a HELLO ACK object MUST also verify that the neighbor is reflecting back the receiver's Instance value. If the neighbor advertises a wrong value in the Dst_Instance field, then a node MUST treat the neighbor as if communication has been lost. If no Instance values are received, via either REQUEST or ACK objects, from a neighbor within a configured number of hello_intervals, then a node MUST presume that it cannot communicate with the neighbor. The default for this number is 3.5. When communication is lost or presumed to be lost as described above, a node MAY re-initiate HELLOs. If a node does re-initiate it MUST use a Src_Instance value different than the one advertised in the previous HELLO message. This new value MUST continue to be advertised to the corresponding neighbor until a reset or reboot occurs, or until another communication failure is detected. If a new instance value has not been received from the neighbor, then the node MUST advertise zero in the Dst_instance value field.5.4. Multi-Link Considerations
As previously noted, the Hello extension is targeted at detecting node failures not per link failures. When there is only one link between neighboring nodes or when all links between a pair of nodes fail, the distinction between node and link failures is not really meaningful and handling of such failures has already been covered. When there are multiple links shared between neighbors, there are special considerations. When the links between neighbors are numbered, then Hellos MUST be run on each link and the previously described mechanisms apply. When the links are unnumbered, link failure detection MUST be provided by some means other than Hellos. Each node SHOULD use a single Hello exchange with the neighbor. The case where all links have failed, is the same as the no received value case mentioned in the previous section.
5.5. Compatibility
The Hello extension does not affect the processing of any other RSVP message. The only effect is to allow a link (node) down event to be declared sooner than it would have been. RSVP response to that condition is unchanged. The Hello extension is fully backwards compatible. The Hello class is assigned a class value of the form 0bbbbbbb. Depending on the implementation, implementations that do not support the extension will either silently discard Hello messages or will respond with an "Unknown Object Class" error. In either case the sender will fail to see an acknowledgment for the issued Hello.6. Security Considerations
In principle these extensions to RSVP pose no security exposures over and above RFC 2205[1]. However, there is a slight change in the trust model. Traffic sent on a normal RSVP session can be filtered according to source and destination addresses as well as port numbers. In this specification, filtering occurs only on the basis of an incoming label. For this reason an administration may wish to limit the domain over which LSP tunnels can be established. This can be accomplished by setting filters on various ports to deny action on a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7) or LSP_TUNNEL_IPv6 (8).7. IANA Considerations
IANA assigns values to RSVP protocol parameters. Within the current document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are defined. Each of these objects contain subobjects. This section defines the rules for the assignment of subobject numbers. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [15]. EXPLICIT_ROUTE Subobject Type EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies the function of the subobject. There are no range restrictions. All possible values are available for assignment. Following the policies outlined in [15], subobject types in the range 0 - 63 (0x00 - 0x3F) are allocated through an IETF Consensus action, codes in the range 64 - 95 (0x40 - 0x5F) are allocated as First Come First Served, and codes in the range 96 - 127 (0x60 - 0x7F) are reserved for Private Use.
ROUTE_RECORD Subobject Type
ROUTE_RECORD Subobject Type is an 8-bit number that identifies the
function of the subobject. There are no range restrictions. All
possible values are available for assignment.
Following the policies outlined in [15], subobject types in the
range 0 - 127 (0x00 - 0x7F) are allocated through an IETF
Consensus action, codes in the range 128 - 191 (0x80 - 0xBF) are
allocated as First Come First Served, and codes in the range 192 -
255 (0xC0 - 0xFF) are reserved for Private Use.
The following assignments are made in this document.
7.1. Message Types
Message Message
Number Name
20 Hello
7.2. Class Numbers and C-Types
Class Class
Number Name
1 SESSION
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
10 FILTER_SPEC
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
11 SENDER_TEMPLATE
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
16 RSVP_LABEL
Class Types or C-Types:
1 Type 1 Label
19 LABEL_REQUEST
Class Types or C-Types:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
Class Types or C-Types:
1 Type 1 Explicit Route
21 ROUTE_RECORD
Class Types or C-Types:
1 Type 1 Route Record
22 HELLO
Class Types or C-Types:
1 Request
2 Acknowledgment
207 SESSION_ATTRIBUTE
Class Types or C-Types:
1 LSP_TUNNEL_RA
7 LSP Tunnel
7.3. Error Codes and Globally-Defined Error Value Sub-Codes
The following list extends the basic list of Error Codes and Values that are defined in [RFC2205]. Error Code Meaning 24 Routing Problem This Error Code has the following globally-defined Error Value sub-codes: 1 Bad EXPLICIT_ROUTE object 2 Bad strict node 3 Bad loose node 4 Bad initial subobject 5 No route available toward destination 6 Unacceptable label value 7 RRO indicated routing loops 8 MPLS being negotiated, but a non-RSVP-capable router stands in the path 9 MPLS label allocation failure 10 Unsupported L3PID 25 Notify Error This Error Code has the following globally-defined Error Value sub-codes: 1 RRO too large for MTU 2 RRO Notification 3 Tunnel locally repaired7.4. Subobject Definitions
Subobjects of the EXPLICIT_ROUTE object with C-Type 1: 1 IPv4 prefix 2 IPv6 prefix 32 Autonomous system number
Subobjects of the RECORD_ROUTE object with C-Type 1:
1 IPv4 address
2 IPv6 address
3 Label
8. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
9. Acknowledgments
This document contains ideas as well as text that have appeared in
previous Internet Drafts. The authors of the current document wish
to thank the authors of those drafts. They are Steven Blake, Bruce
Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun
Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex
Mondrus for their comments on this document.
10. References
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC 2205, September 1997.
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus,
"Requirements for Traffic Engineering over MPLS", RFC 2702,
September 1999.
[4] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992.
[8] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000. [10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, December 2001. [11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [14] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998. [15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [16] Bernet, Y., Smiht, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
11. Authors' Addresses
Daniel O. Awduche Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Voice: +1 703-298-5291 EMail: awduche@movaz.com Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Voice: +1 703 847 1801 EMail: lberger@movaz.com Der-Hwa Gan Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 EMail: dhg@juniper.net Tony Li Procket Networks 3910 Freedom Circle, Ste. 102A Santa Clara CA 95054 EMail: tli@procket.com Vijay Srinivasan Cosine Communications, Inc. 1200 Bridge Parkway Redwood City, CA 94065 Voice: +1 650 628 4892 EMail: vsriniva@cosinecom.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 EMail: swallow@cisco.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, 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 procedures 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 ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.