rfc3032.txt

RFC 的详细文档！

   field, where the PPP Protocol field indicates either type hex 0281
   (MPLS Unicast) or type hex 0283 (MPLS Multicast).  The maximum length
   of a labeled packet transmitted over a PPP link is the same as the
   maximum length of the Information field of a PPP encapsulated packet.

   The format of the Information field itself is as defined in section
   2.

   Note that two codepoints are defined for labeled packets; one for
   multicast and one for unicast.  Once the MPLSCP has reached the
   Opened state, both label switched multicasts and label switched
   unicasts can be sent over the PPP link.

4.4. Label Switching Control Protocol Configuration Options

   There are no configuration options.

5. Transporting Labeled Packets over LAN Media

   Exactly one labeled packet is carried in each frame.

   The label stack entries immediately precede the network layer header,
   and follow any data link layer headers, including, e.g., any 802.1Q
   headers that may exist.

   The ethertype value 8847 hex is used to indicate that a frame is
   carrying an MPLS unicast packet.

   The ethertype value 8848 hex is used to indicate that a frame is
   carrying an MPLS multicast packet.

   These ethertype values can be used with either the ethernet
   encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled
   packets.  The procedure for choosing which of these two
   encapsulations to use is beyond the scope of this document.





Rosen, et al.               Standards Track                    [Page 18]

RFC 3032               MPLS Label Stack Encoding            January 2001


6. IANA Considerations

   Label values 0-15 inclusive have special meaning, as specified in
   this document, or as further assigned by IANA.

   In this document, label values 0-3 are specified in section 2.1.

   Label values 4-15 may be assigned by IANA, based on IETF Consensus.

7. Security Considerations

   The MPLS encapsulation that is specified herein does not raise any
   security issues that are not already present in either the MPLS
   architecture [1] or in the architecture of the network layer protocol
   contained within the encapsulation.

   There are two security considerations inherited from the MPLS
   architecture which may be pointed out here:

      -  Some routers may implement security procedures which depend on
         the network layer header being in a fixed place relative to the
         data link layer header.  These procedures will not work when
         the MPLS encapsulation is used, because that encapsulation is
         of a 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. 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.











Rosen, et al.               Standards Track                    [Page 19]

RFC 3032               MPLS Label Stack Encoding            January 2001


9. Authors' Addresses

   Eric C. Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]


   Dan Tappan
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]


   Yakov Rekhter
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089

   EMail: [e-mail]


   Guy Fedorkow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]


   Dino Farinacci
   Procket Networks, Inc.
   3910 Freedom Circle, Ste. 102A
   Santa Clara, CA 95054

   EMail: [e-mail]











Rosen, et al.               Standards Track                    [Page 20]

RFC 3032               MPLS Label Stack Encoding            January 2001


   Tony Li
   Procket Networks, Inc.
   3910 Freedom Circle, Ste. 102A
   Santa Clara, CA 95054

   EMail: [e-mail]


   Alex Conta
   TranSwitch Corporation
   3 Enterprise Drive
   Shelton, CT, 06484

   EMail: [e-mail]





































Rosen, et al.               Standards Track                    [Page 21]

RFC 3032               MPLS Label Stack Encoding            January 2001


10. References

   [1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
       Switching Architecture", RFC 3031, January 2001.

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
       September 1981.

   [4] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.

   [5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.

   [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
       RFC 1661, July 1994.

   [7] Conta, A. and S. Deering, "Internet Control Message Protocol
       (ICMPv6) for the Internet Protocol Version 6 (IPv6)
       Specification", RFC 1885, December 1995.

   [8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
       version 6", RFC 1981, August 1996.

   [9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E.
       and G. Swallow, "MPLS Using LDP and ATM VC Switching", RFC 3035,
       January 2001.






















Rosen, et al.               Standards Track                    [Page 22]

RFC 3032               MPLS Label Stack Encoding            January 2001


11. 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.



















Rosen, et al.               Standards Track                    [Page 23]