--- 1/draft-ietf-mpls-label-encaps-07.txt 2006-02-05 00:39:38.000000000 +0100 +++ 2/draft-ietf-mpls-label-encaps-08.txt 2006-02-05 00:39:38.000000000 +0100 @@ -1,28 +1,29 @@ + Network Working Group Eric C. Rosen Internet Draft Yakov Rekhter -Expiration Date: March 2000 Daniel Tappan - Dino Farinacci +Expiration Date: January 2001 Daniel Tappan Guy Fedorkow Cisco Systems, Inc. + Dino Farinacci Tony Li - Juniper Networks, Inc. + Procket Networks, Inc. Alex Conta - Lucent Technologies + TranSwitch Corporation - September 1999 + July 2000 MPLS Label Stack Encoding - draft-ietf-mpls-label-encaps-07.txt + draft-ietf-mpls-label-encaps-08.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. @@ -33,21 +34,21 @@ 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 - "Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of + "Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which support MPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on PPP data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques @@ -84,21 +85,21 @@ 4.4 Label Switching Control Protocol Configuration Options . 19 5 Transporting Labeled Packets over LAN Media ............ 19 6 IANA Considerations .................................... 20 7 Security Considerations ................................ 20 8 Intellectual Property .................................. 20 9 Authors' Addresses ..................................... 21 10 References ............................................. 22 1. Introduction - "Multi-Protocol Label Switching (MPLS)" [1,2] requires a set of + "Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which support MPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on PPP data links and on LAN data links. The specified encoding may also be useful for other data links as @@ -115,21 +116,21 @@ LSRs that are implemented on certain switching devices (such as ATM switches) may use different encoding techniques for encoding the top one or two entries of the label stack. When the label stack has additional entries, however, the encoding technique described in this document MUST be used for the additional label stack entries. 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [3]. + document are to be interpreted as described in RFC 2119 [2]. 2. The Label Stack 2.1. Encoding the Label Stack The label stack is represented as a sequence of "label stack entries". Each label stack entry is represented by 4 octets. This is shown in Figure 1. 0 1 2 3 @@ -186,45 +187,45 @@ label stack. In addition to learning the next hop and the label stack operation, one may also learn the outgoing data link encapsulation, and possibly other information which is needed in order to properly forward the packet. There are several reserved label values: i. A value of 0 represents the "IPv4 Explicit NULL Label". - This label value is only legal when it is the sole - label stack entry. It indicates that the label stack - must be popped, and the forwarding of the packet must - then be based on the IPv4 header. + This label value is only legal at the bottom of the + label stack. It indicates that the label stack must be + popped, and the forwarding of the packet must then be + based on the IPv4 header. ii. A value of 1 represents the "Router Alert Label". This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual forwarding of the packet is determined by the label beneath it in the stack. However, if the packet is forwarded further, the Router Alert Label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the - use of the "Router Alert Option" in IP packets [6]. + use of the "Router Alert Option" in IP packets [5]. Since this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol. iii. A value of 2 represents the "IPv6 Explicit NULL Label". - This label value is only legal when it is the sole - label stack entry. It indicates that the label stack - must be popped, and the forwarding of the packet must - then be based on the IPv6 header. + This label value is only legal at the bottom of the + label stack. It indicates that the label stack must be + popped, and the forwarding of the packet must then be + based on the IPv6 header. iv. A value of 3 represents the "Implicit NULL Label". This is a label that an LSR may assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is "Implicit NULL", the LSR will pop the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol, so a value is @@ -414,25 +415,25 @@ of the IP header checksum. It is recognized that there may be situations where a network administration prefers to decrement the IPv4 TTL by one as it traverses an MPLS domain, instead of decrementing the IPv4 TTL by the number of LSP hops within the domain. 2.4.4. Translating Between Different Encapsulations Sometimes an LSR may receive a labeled packet over, e.g., a label - switching controlled ATM (LC-ATM) interface [10], and may need to - send it out over a PPP or LAN link. Then the incoming packet will - not be received using the encapsulation specified in this document, - but the outgoing packet will be sent using the encapsulation - specified in this document. + switching controlled ATM (LC-ATM) interface [9], and may need to send + it out over a PPP or LAN link. Then the incoming packet will not be + received using the encapsulation specified in this document, but the + outgoing packet will be sent using the encapsulation specified in + this document. In this case, the value of the "incoming TTL" is determined by the procedures used for carrying labeled packets on, e.g., LC-ATM interfaces. TTL processing then proceeds as described above. Sometimes an LSR may receive a labeled packet over a PPP or a LAN link, and may need to send it out, say, an LC-ATM interface. Then the incoming packet will be received using the encapsulation specified in this document, but the outgoing packet will not be sent using the encapsulation specified in this document. In this case, @@ -451,32 +452,32 @@ which was originally small enough to be transmitted on that link becomes too large by virtue of having one or more additional labels pushed onto its label stack. In label switching, a packet may grow in size if additional labels get pushed on. Thus if one receives a labeled packet with a 1500-byte frame payload, and pushes on an additional label, one needs to forward it as frame with a 1504-byte payload. This section specifies the rules for processing labeled packets which are "too large". In particular, it provides rules which ensure that - hosts implementing Path MTU Discovery [5], and hosts using IPv6 - [8,9], will be able to generate IP datagrams that do not need + hosts implementing Path MTU Discovery [4], and hosts using IPv6 + [7,8], will be able to generate IP datagrams that do not need fragmentation, even if those datagrams get labeled as they traverse the network. - In general, IPv4 hosts which do not implement Path MTU Discovery [5] + In general, IPv4 hosts which do not implement Path MTU Discovery [4] send IP datagrams which contain no more than 576 bytes. Since the MTUs in use on most data links today are 1500 bytes or more, the probability that such datagrams will need to get fragmented, even if they get labeled, is very small. - Some hosts that do not implement Path MTU Discovery [5] will generate + Some hosts that do not implement Path MTU Discovery [4] will generate IP datagrams containing 1500 bytes, as long as the IP Source and Destination addresses are on the same subnet. These datagrams will not pass through routers, and hence will not get fragmented. Unfortunately, some hosts will generate IP datagrams containing 1500 bytes, as long the IP Source and Destination addresses have the same classful network number. This is the one case in which there is any risk of fragmentation when such datagrams get labeled. (Even so, fragmentation is not likely unless the packet must traverse an ethernet of some sort between the time it first gets labeled and the @@ -637,24 +638,24 @@ c. Forward the fragments 4. If the IP datagram has the "Don't Fragment" bit set in its IP header: a. the datagram MUST NOT be forwarded b. Create an ICMP Destination Unreachable Message: - i. set its Code field [4] to "Fragmentation Required + i. set its Code field [3] to "Fragmentation Required and DF Set", - ii. set its Next-Hop MTU field [5] to the difference + ii. set its Next-Hop MTU field [4] to the difference between the Effective Maximum Frame Payload Size and the value of N c. If possible, transmit the ICMP Destination Unreachable Message to the source of the of the discarded datagram. 3.5. Processing Labeled IPv6 Datagrams which are Too Big To process a labeled IPv6 datagram which is too big, an LSR MUST execute the following algorithm: @@ -689,21 +690,21 @@ c. Forward the fragments. Reassembly of the fragments will be done at the destination host. 3.6. Implications with respect to Path MTU Discovery The procedures described above for handling datagrams which have the DF bit set, but which are "too large", have an impact on the Path MTU - Discovery procedures of RFC 1191 [5]. Hosts which implement these + Discovery procedures of RFC 1191 [4]. Hosts which implement these procedures will discover an MTU which is small enough to allow n labels to be pushed on the datagrams, without need for fragmentation, where n is the number of labels that actually get pushed on along the path currently in use. In other words, datagrams from hosts that use Path MTU Discovery will never need to be fragmented due to the need to put on a label header, or to add new labels to an existing label header. (Also, datagrams from hosts that use Path MTU Discovery generally have the DF bit set, and so will never get fragmented anyway.) @@ -726,21 +727,21 @@ - Any time the transmitting endpoint of the tunnel needs to send a packet into the tunnel, and that packet has the DF bit set, and it exceeds the tunnel MTU, the transmitting endpoint of the tunnel MUST send the ICMP Destination Unreachable message to the source, with code "Fragmentation Required and DF Set", and the Next-Hop MTU Field set as described above. 4. Transporting Labeled Packets over PPP - The Point-to-Point Protocol (PPP) [7] provides a standard method for + The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This section defines the Network Control Protocol for establishing and configuring label Switching over PPP. 4.1. Introduction @@ -770,21 +771,21 @@ 4.2. A PPP Network Control Protocol for MPLS The MPLS Control Protocol (MPLSCP) is responsible for enabling and disabling the use of label switching on a PPP link. It uses the same packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. MPLSCP packets received before this phase is reached should be silently discarded. The MPLS Control Protocol is exactly the same as the Link Control - Protocol [7] with the following exceptions: + Protocol [6] with the following exceptions: 1. Frame Modifications The packet may utilize any modifications to the basic frame format which have been negotiated during the Link Establishment phase. 2. Data Link Layer Protocol Field Exactly one MPLSCP packet is encapsulated in the PPP @@ -902,73 +903,69 @@ 250 Apollo Drive Chelmsford, MA, 01824 E-mail: erosen@cisco.com Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: tappan@cisco.com - Dino Farinacci - Cisco Systems, Inc. - 170 Tasman Drive - San Jose, CA, 95134 - E-mail: dino@cisco.com - Yakov Rekhter Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: yakov@cisco.com Guy Fedorkow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: fedorkow@cisco.com + Dino Farinacci + Procket Networks, Inc. + 3910 Freedom Circle, Ste. 102A + Santa Clara, CA 95054 + E-mail: dino@procket.com + Tony Li - Juniper Networks - 385 Ravendale Dr. - Mountain View, CA, 94043 - E-mail: tli@juniper.net + Procket Networks, Inc. + 3910 Freedom Circle, Ste. 102A + Santa Clara, CA 95054 + E-mail: tli@procket.com Alex Conta - Lucent Technologies - 300 Baker Avenue - Concord, MA, 01742 - E-mail: aconta@lucent.com + TranSwitch Corporation + 3 Enterprise Drive + Shelton, CT, 06484 + E-mail: aconta@txc.com 10. References [1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label - Switching Architecture", Work in Progress, April 1999. - - [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G., - Viswanathan, A., "A Framework for Multiprotocol Label Switching", - Work in Progress, November 1997. + Switching Architecture", Work in Progress, July 2000. - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. - [4] Postel, J., "Internet Control Message Protocol", RFC 792, + [3] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981. - [5] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191, + [4] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191, November 1990. - [6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. + [5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. - [7] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC + [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 51, July 1994. - [8] Conta, A. and Deering, S., "Internet Control Message Protocol + [7] Conta, A. and Deering, S., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995. - [9] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP + [8] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP version 6", RFC 1981, August 1996. - [10] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. + [9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in - Progress, April 1999. + Progress, June 2000.