draft-ietf-mpls-icmp-02.txt | draft-ietf-mpls-icmp-03.txt | |||
---|---|---|---|---|
MPLS Working Group R.Bonica | MPLS Working Group R.Bonica | |||
Internet Draft MCIWorldCom | Internet-Draft D. Gan | |||
Document: draft-ietf-mpls-icmp-02.txt D.Tappan | Expires: February 3, 2006 Juniper Networks | |||
Cisco Systems | D. Tappan | |||
D.Gan | Cisco Systems, Inc. | |||
Juniper Networks | August 2, 2005 | |||
August 2000 | ||||
ICMP Extensions for MultiProtocol Label Switching | ICMP Extensions for MultiProtocol Label Switching | |||
draft-ietf-mpls-icmp-03 | ||||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | By submitting this Internet-Draft, each author represents that any | |||
all provisions of Section 10 of [RFC-2026]. | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. Internet-Drafts are draft documents valid for a maximum of | Drafts. | |||
six months and may be updated, replaced, or obsoleted by other | ||||
documents at any time. It is inappropriate to use Internet-Drafts as | Internet-Drafts are draft documents valid for a maximum of six months | |||
reference material or to cite them other than as "work in progress." | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
1. Abstract | This Internet-Draft will expire on February 3, 2006. | |||
The current memo proposes extensions to ICMP that permit Label | Copyright Notice | |||
Switching Routers to append MPLS information to ICMP messages. | ||||
2. Conventions used in this document | Copyright (C) The Internet Society (2005). | |||
Abstract | ||||
This memo proposes extensions to ICMP that permit Label Switching | ||||
Routers to append MPLS information to ICMP messages. | ||||
Table of Contents | ||||
1. Conventions Used In This Document . . . . . . . . . . . . . . 3 | ||||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
3. Application to TRACEROUTE . . . . . . . . . . . . . . . . . . 5 | ||||
4. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
5.1 Common Header . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
5.2 Object Header . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
5.3 MPLS Stack Entry Object Class . . . . . . . . . . . . . . 9 | ||||
5.4 Extended Payload Object Class . . . . . . . . . . . . . . 10 | ||||
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 | ||||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | ||||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | ||||
9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
Intellectual Property and Copyright Statements . . . . . . . . 15 | ||||
1. Conventions Used In This Document | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
this document are to be interpreted as described in [RFC-2119]. | document are to be interpreted as described in RFC2119 [1]. | |||
3. Introduction | 2. Introduction | |||
Routers and destination hosts use the Internet Control Message | IP routers use the Internet Control Message Protocol (ICMP) [2] to | |||
Protocol (ICMP) [RFC-792] to convey control information to source | convey control information to source hosts. Network operators use | |||
hosts. Network operators use this information to diagnose routing | this information to diagnose routing problems. | |||
problems. | ||||
Bonica, Tappan, Hwa Draft-Expires February 2001 1 | ||||
When a router receives an undeliverable IP datagram, it can send an | When a router receives an undeliverable IP datagram, it can send an | |||
ICMP message to the host that originated the datagram. The ICMP | ICMP message to the host that originated the datagram. The ICMP | |||
message indicates why the datagram could not be delivered. It also | message indicates why the datagram could not be delivered. It also | |||
contains the IP header and leading payload octets of the "original | contains the IP header and leading payload octets of the "original | |||
datagram". | datagram". | |||
In this document, the term "original datagram" refers to the | In this document, the term "original datagram" refers to the datagram | |||
datagram to which the ICMP message is a response. | to which the ICMP message is a response. | |||
MPLS Label Switching Routers (LSR) also use ICMP to convey control | MPLS Label Switching Routers (LSR) also use ICMP to convey control | |||
information to source hosts. Sections 2.3 and 2.4 of [ENCODE] | information to source hosts. Sections 2.3 and 2.4 of RFC 3032 [3] | |||
describe the interaction between MPLS and ICMP. | describe the interaction between MPLS and ICMP. | |||
When an LSR receives an undeliverable MPLS encapsulated datagram, it | When an LSR receives an undeliverable MPLS encapsulated datagram, it | |||
removes the entire MPLS label stack, exposing the previously | removes the entire MPLS label stack, exposing the previously | |||
encapsulated IP datagram. The LSR then submits the IP datagram to a | encapsulated IP datagram. The LSR then submits the IP datagram to an | |||
network-forwarding module for error processing. Error processing can | error processing module. Error processing can include ICMP message | |||
include ICMP message generation. | generation. | |||
The ICMP message indicates why the original datagram could not be | The ICMP message indicates why the original datagram could not be | |||
delivered. It also contains the IP header and leading octets of the | delivered. It also contains the IP header and leading octets of the | |||
original datagram. | original datagram. | |||
The ICMP message, however, includes no information regarding the | The ICMP message, however, contains no information regarding the MPLS | |||
MPLS label stack that encapsulated the original datagram when it | label stack that encapsulated the original datagram when it arrived | |||
arrived at the LSR. This omission is significant because the LSR | at the LSR. This omission is significant because the LSR would have | |||
would have routed the original datagram based upon information | routed the original datagram based upon information contained by the | |||
contained by the MPLS label stack. | MPLS label stack. | |||
The current memo proposes extensions to ICMP that permit an LSR to | This memo proposes extensions to ICMP that permit an LSR to append | |||
append MPLS label stack information to ICMP messages. ICMP messages | MPLS label stack information to ICMP messages. ICMP messages | |||
regarding MPLS encapsulated datagrams SHOULD include the MPLS label | regarding MPLS encapsulated datagrams SHOULD include the MPLS label | |||
stack, as it arrived at the router that is sending the ICMP message. | stack, as it arrived at the router that is sending the ICMP message. | |||
The ICMP message MUST also include the IP header and leading payload | The ICMP message MUST also include the IP header and leading payload | |||
octets of the original datagram. | octets of the original datagram. | |||
Network operators will use this information to diagnose routing | 3. Application to TRACEROUTE | |||
problems. | ||||
4. Motivation | ||||
ICMP extensions defined in the current memo support enhancements to | ICMP extensions defined in this memo support enhancements to | |||
TRACEROUTE. The enhanced TRACEROUTE, like older implementations, | TRACEROUTE. The enhanced TRACEROUTE, like older implementations, | |||
indicates which nodes the original datagram visited en route to its | indicates which nodes the original datagram visited en route to its | |||
ultimate destination. It differs from older implementations in that | destination. It differs from older implementations in that it also | |||
it also indicates the original datagrams MPLS encapsulation status | indicates the original datagrams MPLS encapsulation status as it | |||
as it arrived at each node. | arrived at each node. | |||
Figure 1 contains sample output from an enhanced TRACEROUTE | Figure 1 contains sample output from an enhanced TRACEROUTE | |||
implementation. | implementation. | |||
Bonica,Tappan,Gan Draft-Expires February 2001 2 | > traceroute 100.100.6.1 | |||
>Traceroute 166.45.2.74 | ||||
traceroute to 166.45.2.74, 30 hops max, 40 byte packets | ||||
1 166.45.5.1 1.281 ms 1.103 ms 1.096 ms | ||||
2 166.45.4.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2001 | ||||
mplsExpBits1=0 | ||||
3 166.45.3.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2002 | ||||
mplsExpBits1=0 | ||||
4 166.45.6.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2003 | ||||
mplsExpBits1=0 | ||||
5 166.45.2.1 1.281 ms 1.103 ms 1.096 ms | ||||
6 166.45.2.74 1.281 ms 1.103 ms 1.096 ms | ||||
Figure 1. Enhanced TRACEROUTE sample output | traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets | |||
5. Disclaimer | 1 10.1.1.2 (10.1.1.2) 0.661 ms 0.618 ms 0.579 ms | |||
The current memo does not define the general relationship between | 2 10.1.12.2 (10.1.12.2) 0.861 ms 0.718 ms 0.679 ms | |||
ICMP and MPLS. Sections 2.3 and 2.4 of [ENCODE] define this | ||||
relationship. | ||||
Specifically, this document defers to [ENCODE] with respect to the | MPLS Label=100048 Exp=0 TTL=1 S=1 | |||
3 10.1.24.2 (10.1.24.2) 0.822 ms 0.731 ms 0.708 ms | ||||
MPLS Label=100016 Exp=0 TTL=1 S=1 | ||||
4 10.100.6.1 (10.100.6.1) 0.961 ms 8.676 ms 0.875 ms | ||||
Figure 1: Enhanced TRACEROUTE Sample Output | ||||
4. Disclaimer | ||||
This memo does not define the general relationship between ICMP and | ||||
MPLS. Sections 2.3 and 2.4 of RFC3032 define this relationship. | ||||
Specifically, this document defers to RFC3032 with respect to the | ||||
following issues: | following issues: | |||
- conditions upon which an LSR emits ICMP messages | - conditions upon which an LSR emits ICMP messages | |||
- handling of ICMP messages bound for hosts that are identified | ||||
by private addresses | - handling of ICMP messages bound for hosts that are identified by | |||
private addresses | ||||
The current memo does not define encapsulation specific TTL | The current memo does not define encapsulation specific TTL | |||
manipulation procedures. It defers to Section 10 of [MPLSATM] and | manipulation procedures. It defers to Section 5.4 of RFC 3034 [4] | |||
Section 5.4 of [MPLSFRAME] in this matter. | and Section 10 of RFC 3035 [5] in this matter. | |||
When encapsulation specific TTL manipulation procedures defeat the | When encapsulation specific TTL manipulation procedures defeat the | |||
basic TRACEROUTE mechanism, they will also defeat enhanced | basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE | |||
TRACEROUTE implementations. | implementations. | |||
The current memo does not address extensions to ICMPv6. These should | The current memo does not address extensions to ICMPv6. These should | |||
be addressed in a separate draft. | be addressed in a separate draft. | |||
6. Formal Syntax | 5. Syntax | |||
This section defines a data structure that an LSR can append to | This section defines a data structure that an LSR can append to | |||
selected ICMP messages. The data structure contains the MPLS label | selected ICMP messages. The data structure contains the MPLS label | |||
stack that encapsulated the original datagram when it arrived at the | stack that encapsulated the original datagram when it arrived at the | |||
LSR. | LSR. | |||
The data structure defined herein can be appended to the following | In theory, the data structure defined herein can be appended to the | |||
ICMP message types: | following ICMP message types: | |||
Bonica,Tappan,Gan Draft-Expires February 2001 3 | Destination Unreachable | |||
1) Destination Unreachable | ||||
2) Time Exceeded | Time Exceeded | |||
3) Parameter Problem | ||||
4) Source Quench | Parameter Problem | |||
5) Redirect | ||||
Source Quench | ||||
Redirect | ||||
However, in practice, it would only be useful when appended to the | ||||
Destination Unreachable and Time Exceeded messages. | ||||
According to RFC-792, bytes 0 through 19 of any ICMP message contain | According to RFC-792, bytes 0 through 19 of any ICMP message contain | |||
a header whose format is analogous to that of the IP datagram. Bytes | a header whose format is analogous to that of the IP datagram. Bytes | |||
20 through 23 contain an ICMP message type, code and checksum. Bytes | 20 through 23 contain an ICMP message type, code and checksum. Bytes | |||
24 through 27 contain message specific data. | 24 through 27 contain message specific data. | |||
Also according to RFC-792, the final field contained by each of the | Also according to RFC-792, the final field contained by each of the | |||
ICMP message types listed above begins at byte 28. It reflects the | ICMP message types listed above begins at byte 28. It reflects the | |||
IP header and leading 64 bits of the original datagram. [RFC-1812] | IP header and leading 64 bits of the original datagram. RFC 1812 [6] | |||
recommends that this final field be extended to include as much of | recommends that this final field be extended to include as much of | |||
the original datagram as possible. | the original datagram as possible. | |||
When an LSR appends the data structure defined herein to an ICMP | When an LSR appends the data structure defined herein to an ICMP | |||
message, the final field of the ICMP message body MUST contain the | message, the final field of the ICMP message body MUST contain the | |||
first 128 octets of the original datagram. At least 20 of these 128 | first 128 octets of the original datagram. At least 20 of these 128 | |||
octets represent the IP header of the original datagram. | octets represent the IP header of the original datagram. | |||
If the original datagram was shorter than 128 octets, the final | If the original datagram was shorter than 128 octets, the final field | |||
field MUST be padded with 0's. | MUST be padded with 0's. | |||
When an LSR appends the data structure defined herein to an ICMP | When an LSR appends the data structure defined herein to an ICMP | |||
message, the ICMP "total length" MUST be equal to the data structure | message, the ICMP "total length" MUST be adjusted appropriately to | |||
length plus 156. The first octet of the data structure must be | include the data structure. | |||
displaced 156 octets from the beginning of the ICMP message. | ||||
The data structure defined in this section consists of a common | The data structure defined in this section consists of a common | |||
header followed by object instances. Each object instance consists | header followed by object instances. Each object instance consists | |||
of an object header plus contents. | of an object header plus contents. | |||
Currently, two object classes are defined. One object class contains | Currently, two object classes are defined. One object class contains | |||
an entire MPLS label stack, formatted exactly as it was when it | an entire MPLS label stack, formatted exactly as it was when it | |||
arrived at the LSR that sends the ICMP message. The other contains | arrived at the LSR that sends the ICMP message. The other contains | |||
some portion of the original datagram that could not be included in | some portion of the original datagram that could not be included in | |||
the final field of the ICMP message body (i.e., the octet 129 and | the final field of the ICMP message body (i.e., the octet 129 and | |||
beyond). | beyond). | |||
Both object classes are optional. | Both object classes are optional. | |||
In the future, additional object classes may be defined. | In the future, additional object classes may be defined. | |||
Bonica,Tappan,Gan Draft-Expires February 2001 4 | 5.1 Common Header | |||
6.1 Common Header | ||||
0 1 2 3 | 0 1 2 3 | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| Vers | (Reserved) | Checksum | | | Vers | (Reserved) | Checksum | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
Figure 2: Common Header | ||||
The fields in the common header are as follows: | The fields in the common header are as follows: | |||
Vers: 4 bits | Vers: 4 bits | |||
ICMP extension version number. | ICMP extension version number. This is version 2. | |||
This is version 2. | ||||
Checksum: 16 bits | Checksum: 16 bits | |||
The one's complement of the one's complement sum of the data | The one's complement of the one's complement sum of the data | |||
structure, with the checksum field replaced by zero for the purpose | structure, with the checksum field replaced by zero for the | |||
of computing the checksum. An all-zero value means that no checksum | purpose of computing the checksum. An all-zero value means that | |||
was transmitted. | no checksum was transmitted. | |||
If the checksum field contains a value other than described above, | If the checksum field contains a value other than described above, | |||
the ICMP message does not include the extensions described in this | the ICMP message does not include the extensions described in this | |||
memo. This, however, does not imply that the ICMP message is | memo. This, however, does not imply that the ICMP message is | |||
malformed. It may be in strict compliance with RFC-1812. | malformed. It may be in strict compliance with RFC-1812. | |||
Reserved: Must be set to 0. | Reserved: Must be set to 0. | |||
6.2 Object Header | 5.2 Object Header | |||
Every object consists of one or more 32-bit words with a one-word | Every object consists of one or more 32-bit words with a one-word | |||
header, with the following format: | header. The following is the format of the one-word header: | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| Length | Class-Num | C-Type | | | Length | Class-Num | C-Type | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| | | | | | |||
| // (Object contents) // | | | // (Object contents) // | | |||
| | | | | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
Figure 3: Object Header | ||||
An object header has the following fields: | An object header has the following fields: | |||
Length: 16 bits | Length: 16 bits | |||
Length of the object, measured in octets, including the object | Length of the object, measured in octets, including the object | |||
header and object contents. | header and object contents. | |||
Bonica,Tappan,Gan Draft-Expires February 2001 5 | ||||
Class-Num: 8 bits | Class-Num: 8 bits | |||
Identifies object class. | Identifies object class. | |||
C-Type: 8 bits | C-Type: 8 bits | |||
Identifies object sub-type. | Identifies object sub-type. | |||
6.3 MPLS Stack Entry Object Class | 5.3 MPLS Stack Entry Object Class | |||
A single instance of the MPLS Entry Object class represents the | A single instance of the MPLS Entry Object class represents the | |||
entire MPLS label stack, formatted exactly as it was when it arrived | entire MPLS label stack, formatted exactly as it was when it arrived | |||
at the LSR that sends the ICMP message | at the LSR that sends the ICMP message | |||
In the illustration below, octets 0-3 depict the first member of the | In the illustration below, octets 0-3 depict the first member of the | |||
MPLS label stack. Each remaining member of the MPLS label stack is | MPLS label stack. Each remaining member of the MPLS label stack is | |||
represented by another 4 octets that share the same format. | represented by another 4 octets that share the same format. | |||
Syntax follows: | Syntax follows: | |||
skipping to change at line 277 | skipping to change at page 10, line 14 | |||
0 1 2 3 | 0 1 2 3 | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| Label |EXP |S| TTL | | | Label |EXP |S| TTL | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| | | | | | |||
| // Remaining MPLS Stack Entries // | | | // Remaining MPLS Stack Entries // | | |||
| | | | | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
Figure 4: MPLS Stack Entry Object Class | ||||
Label: 20 bits | Label: 20 bits | |||
Exp: Experimental Use, 3 bits | Exp: Experimental Use, 3 bits | |||
S: Bottom of Stack, 1 bit | S: Bottom of Stack, 1 bit | |||
TTL: Time to Live, 8 bits | TTL: Time to Live, 8 bits | |||
6.4 Extended Payload Object Class | 5.4 Extended Payload Object Class | |||
An instance of the Extended Payload Object class represents some | An instance of the Extended Payload Object class represents some | |||
portion of the original datagram that could not be fit in the final | portion of the original datagram that could not be fit in the final | |||
field of the ICMP message body (i.e., octets beyond 128). | field of the ICMP message body (i.e., octets beyond 128). | |||
Bonica,Tappan,Gan Draft-Expires February 2001 6 | ||||
Syntax follows: | Syntax follows: | |||
MPLS Stack Entry Class = 2, C-Type = 1. | MPLS Stack Entry Class = 2, C-Type = 1. | |||
0 1 2 3 | 0 1 2 3 | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| | | | | | |||
| // Additional bytes of original datagram // | | | // Additional bytes of original datagram // | | |||
| | | | | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
7. Backward Compatibility | Figure 5: Extended Payload Object Class | |||
ICMP extensions proposed in this document MUST be backward | 6. Backward Compatibility | |||
compatible with the syntax described in RFC-792. Extensions proposed | ||||
in this memo MUST NOT change or deprecate any field defined in RFC- | ICMP extensions proposed in this document MUST be backward compatible | |||
792. | with the syntax described in RFC-792. Extensions proposed in this | |||
memo MUST NOT change or deprecate any field defined in RFC-792. | ||||
The extensions defined herein are in keeping with the spirit, if not | The extensions defined herein are in keeping with the spirit, if not | |||
the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC- | the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC- | |||
1812 extends the final field of selected ICMP messages to include a | 1812 extends the final field of selected ICMP messages to include a | |||
greater portion of the original datagram. Unfortunately, it extends | greater portion of the original datagram. Unfortunately, it extends | |||
this field to a variable length without adding a length attribute. | this field to a variable length without adding a length attribute. | |||
This memo binds the length of that final field to an arbitrarily | This memo binds the length of that final field to an arbitrarily | |||
large value (128 octets). Fixing the length of that field | large value (128 octets). Fixing the length of that field | |||
facilitates extension of the ICMP message. An additional object is | facilitates extension of the ICMP message. An additional object is | |||
provided through which octets 129 and beyond can be appended to the | provided through which octets 129 and beyond can be appended to the | |||
ICMP message. | ICMP message. | |||
As few datagrams contain L3 or L4 header information beyond octet | As few datagrams contain L3 or L4 header information beyond octet | |||
128, it is unlikely that the extensions described herein will | 128, it is unlikely that the extensions described herein will disable | |||
disable any applications that rely upon RFC-1812 style ICMP | any applications that rely upon RFC-1812 style ICMP messages. | |||
messages. | ||||
8. Security Considerations | 7. Security Considerations | |||
This memo presents no security considerations beyond those already | This memo presents no security considerations beyond those already | |||
presented by current ICMP applications (e.g., traceroute). | presented by current ICMP applications (e.g., traceroute). | |||
9. References | 8. IANA Considerations | |||
[ARCH], Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | IANA should establish a registry of ICMP extention classes and class- | |||
Label Switching Architecture", Internet Draft <draft-ietf-mpls-arch- | sub-types. | |||
06.txt>, August, 1999 | ||||
Bonica,Tappan,Gan Draft-Expires February 2001 7 | 9. Normative References | |||
[ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D., | ||||
Fedorkow, G., Li, T., Conta, A., "MPLS Stack Encoding", Internet | ||||
Draft, <draft-ietf-mpls-label-encapse-07.txt>, September 1999. | ||||
[MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., | [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Rosen, E., Swallow, G, "MPLS using LDP and ATM VC Switching", | Levels", BCP 14, RFC 2119, March 1997. | |||
<draft-ietf- mpls-atm-04.txt>, June 2000. | ||||
[MPLSFRAME], Conta, A., Doolan, P., Malis, A., "Use of Label | [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, | |||
Switching on Frame Relay Networks", <draft-ietf-mpls-fr-06.txt>, | September 1981. | |||
June, 2000. | ||||
[RFC-792], Postel, J., "Internet Control Message Protocol", RFC 792, | [3] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., | |||
ISI, September 1981. | Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, | |||
January 2001. | ||||
[RFC-1812], Baker, F., "Requirements for IP Version 4 Routers", RFC | [4] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on | |||
1812, June 1995. | Frame Relay Networks Specification", RFC 3034, January 2001. | |||
[RFC-2026], Bradner, S., "Internet Standards Process Revision 3", | [5] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., | |||
RFC 2026, Harvard University, October 1996. | Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC | |||
Switching", RFC 3035, January 2001. | ||||
[RFC-2119], Bradner, S,, "Key words for use in RFCs to Indicate | [6] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, | |||
Requirement Levels", RFC 2119, Harvard University, March 1997 | June 1995. | |||
10. Acknowledgments | Authors' Addresses | |||
Thanks to Yakov Rekhter and Mike Heard for their contributions to | Ronald P. Bonica | |||
this memo. | Juniper Networks | |||
2251 Corporate Park Drive | ||||
Herndon, VA 20171 | ||||
US | ||||
11. Author's Addresses | Email: rbonica@juniper.net | |||
Ronald P. Bonica | Der-Hwa Gan | |||
MCI WorldCom | Juniper Networks | |||
22001 Loudoun County Pkwy | 1194 N. Mathilda Ave. | |||
Ashburn, Virginia, 20147 | Sunnyvale, CA 94089 | |||
Phone: 703 886 1681 | US | |||
Email: rbonica@mci.net | ||||
Email: dhg@juniper.net | ||||
Daniel C. Tappan | Daniel C. Tappan | |||
Cisco Systems | Cisco Systems, Inc. | |||
250 Apollo Drive | 250 Apollo Drive | |||
Chelmsford, Massachusetts, 01824 | Chelmsford, MA 01824 | |||
US | ||||
Email: tappan@cisco.com | Email: tappan@cisco.com | |||
Der-Hwa Gan | Intellectual Property Statement | |||
Juniper Networks | ||||
385 Ravendale Drive | ||||
Mountain View, California 94043 | ||||
Bonica,Tappan,Gan Draft-Expires February 2001 8 | ||||
Email: dhg@juniper.net | ||||
Bonica,Tappan,Gan Draft-Expires February 2001 9 | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Full Copyright Statement | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
"Copyright (C) The Internet Society (date). All Rights Reserved. | The IETF invites any interested party to bring to its attention any | |||
This document and translations of it may be copied and furnished to | copyrights, patents or patent applications, or other proprietary | |||
others, and derivative works that comment on or otherwise explain it | rights that may cover technology that may be required to implement | |||
or assist in its implmentation may be prepared, copied, published | this standard. Please address the information to the IETF at | |||
and distributed, in whole or in part, without restriction of any | ietf-ipr@ietf.org. | |||
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 | ||||
Bonica,Tappan,Gan Draft-Expires February 2001 10 | Disclaimer of Validity | |||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Copyright Statement | ||||
Copyright (C) The Internet Society (2005). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | ||||
Acknowledgment | ||||
Funding for the RFC Editor function is currently provided by the | ||||
Internet Society. | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |