One document matched: draft-rosen-mpls-lan-encaps-00.txt

Network Working Group                                      Eric C. Rosen
Internet Draft                                             Yakov Rekhter
Expiration Date: May 1998                                  Daniel Tappan
                                                          Dino Farinacci
                                                            Guy Fedorkow
                                                     Cisco Systems, Inc.

                                                                 Tony Li
                                                  Juniper Networks, Inc.

                                                              Alex Conta
                                                     Lucent Technologies

                                                           November 1997


                 MPLS Label Stack Encoding on LAN Media


                   draft-rosen-mpls-lan-encaps-00.txt

Status of this Memo

   This document is an Internet-Draft.  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.

   Internet-Drafts are draft documents valid for a maximum of six months
   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."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   ''Multi-Protocol Label Switching (MPLS)'' [1,2,3] requires a set of
   procedures for augmenting network layer packets with ''label stacks'',
   thereby turning them into ''labeled packets'' [4].  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



Rosen, et al.                                                   [Page 1]


Internet Draft     draft-rosen-mpls-lan-encaps-00.txt      November 1997


   specifies the encoding to be used by an LSR in order to transmit
   labeled packets on LAN data links.


Table of Contents

    1      Introduction  ...........................................   2
    1.1    Specification of Requirements  ..........................   2
    2      Transporting Labeled Packets over LAN Media  ............   3
    3      Security Considerations  ................................   3
    4      Authors' Addresses  .....................................   4
    5      References  .............................................   5





1. Introduction

   "Multi-Protocol Label Switching (MPLS)" [1,2,3] requires a set of
   procedures for augmenting network layer packets with "label stacks",
   thereby turning them into "labeled packets" [4].  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 LAN data links.


1.1. Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

        MUST

        This word, or the adjective "required", means that the
        definition is an absolute requirement of the specification.

        MUST NOT

        This phrase means that the definition is an absolute prohibition
        of the specification.

        SHOULD




Rosen, et al.                                                   [Page 2]


Internet Draft     draft-rosen-mpls-lan-encaps-00.txt      November 1997


        This word, or the adjective "recommended", means that there may
        exist valid reasons in particular circumstances to ignore this
        item, but the full implications must be understood and carefully
        weighed before choosing a different course.

        MAY

        This word, or the adjective "optional", means that this item is
        one of an allowed set of alternatives.  An implementation which
        does not include this option MUST be prepared to interoperate
        with another implementation which does include the option.


2. Transporting Labeled Packets over LAN Media

   The label stack MUST be represented and processed as specified in
   [4].

   Each LAN frame that carries a labeled packet MUST carry exactly one
   labeled packet.

   The label stack entries MUST immediately precede the network layer
   header, and MUST follow any data link layer headers, including, e.g.,
   any VLAN headers, 802.1Q headers, etc. 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 SNAP/SAP encapsulation to carry labeled
   packets.

   The procedures for processing labeled packets are as specified in
   [4].


3. Security Considerations

   Security considerations are not discussed in this document.









Rosen, et al.                                                   [Page 3]


Internet Draft     draft-rosen-mpls-lan-encaps-00.txt      November 1997


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

   Tony Li
   Juniper Networks
   3260 Jay Street
   Santa Clara, CA 95051
   E-mail: tli@jnx.com

   Alex Conta
   Lucent Technologies
   300 Baker Avenue
   Concord, MA, 01742
   E-mail: aconta@lucent.com








Rosen, et al.                                                   [Page 4]


Internet Draft     draft-rosen-mpls-lan-encaps-00.txt      November 1997


5. References

   [1], "A Proposed Architecture for MPLS", 7/97, draft-ietf-mpls-arch-
   00.txt, Rosen, Viswanathan, Callon

   [2] "A Framework for Multiprotocol Label Switching", 7/97, draft-
   ietf-mpls-framework-01.txt, Callon, Doolan, Feldman, Fredette,
   Swallow, Visanathawan

   [3] "Tag Switching Architecture - Overview", 7/97, draft-rekhter-
   tagswitch-arch-01.txt, Rekhter, Davie, Katz, Rosen, Swallow

   [4] "MPLS Label Stack Encoding", 11/97, draft-ietf-mpls-label-
   encaps-00.txt, Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li,
   Conta.




































Rosen, et al.                                                   [Page 5]