--- 1/draft-ietf-mpls-label-encaps-04.txt 2006-02-05 00:39:35.000000000 +0100 +++ 2/draft-ietf-mpls-label-encaps-05.txt 2006-02-05 00:39:35.000000000 +0100 @@ -1,28 +1,28 @@ Network Working Group Eric C. Rosen Internet Draft Yakov Rekhter -Expiration Date: October 1999 Daniel Tappan +Expiration Date: February 2000 Daniel Tappan Dino Farinacci Guy Fedorkow Cisco Systems, Inc. Tony Li Juniper Networks, Inc. Alex Conta Lucent Technologies - April 1999 + August 1999 MPLS Label Stack Encoding - draft-ietf-mpls-label-encaps-04.txt + draft-ietf-mpls-label-encaps-05.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,24 +33,24 @@ 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 - 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 + "Multi-Protocol Label Switching (MPLS)" [1,2] 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 described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding. @@ -78,22 +78,23 @@ 3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 15 3.6 Implications with respect to Path MTU Discovery ........ 16 4 Transporting Labeled Packets over PPP .................. 17 4.1 Introduction ........................................... 17 4.2 A PPP Network Control Protocol for MPLS ................ 18 4.3 Sending Labeled Packets ................................ 19 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 Authors' Addresses ..................................... 20 - 9 References ............................................. 21 + 8 Intellectual Property .................................. 20 + 9 Authors' Addresses ..................................... 21 + 10 References ............................................. 22 1. Introduction "Multi-Protocol Label Switching (MPLS)" [1,2] 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. @@ -877,21 +878,28 @@ variable size. - An MPLS label has its meaning by virtue of an agreement between the LSR that puts the label in the label stack (the "label writer") , and the LSR that interprets that label (the "label reader"). However, the label stack does not provide any means of determining who the label writer was for any particular label. If labeled packets are accepted from untrusted sources, the result may be that packets are routed in an illegitimate manner. -8. Authors' Addresses +8. Intellectual Property + + 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. Authors' Addresses Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: erosen@cisco.com Dan Tappan Cisco Systems, Inc. 250 Apollo Drive @@ -921,21 +929,21 @@ 385 Ravendale Dr. Mountain View, CA, 94043 E-mail: tli@juniper.net Alex Conta Lucent Technologies 300 Baker Avenue Concord, MA, 01742 E-mail: aconta@lucent.com -9. References +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. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.