home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rosen-tag-stack-00.txt < prev    next >
Text File  |  1996-11-20  |  15KB  |  510 lines
  1.  
  2. Network Working Group                                      Eric C. Rosen
  3. Internet Draft                                       Cisco Systems, Inc.
  4. Expiration Date: May 1997
  5.                                                            Daniel Tappan
  6.                                                      Cisco Systems, Inc.
  7.  
  8.                                                           Dino Farinacci
  9.                                                      Cisco Systems, Inc.
  10.  
  11.                                                            Yakov Rekhter
  12.                                                      Cisco Systems, Inc.
  13.  
  14.                                                             Guy Fedorkow
  15.                                                      Cisco Systems, Inc.
  16.  
  17.                                                            November 1996
  18.  
  19.  
  20.                    Tag Switching: Tag Stack Encodings
  21.  
  22.  
  23.                       draft-rosen-tag-stack-00.txt
  24.  
  25. Status of this Memo
  26.  
  27.    This document is an Internet-Draft.  Internet-Drafts are working
  28.    documents of the Internet Engineering Task Force (IETF), its areas,
  29.    and its working groups.  Note that other groups may also distribute
  30.    working documents as Internet-Drafts.
  31.  
  32.    Internet-Drafts are draft documents valid for a maximum of six months
  33.    and may be updated, replaced, or obsoleted by other documents at any
  34.    time.  It is inappropriate to use Internet-Drafts as reference
  35.    material or to cite them other than as "work in progress."
  36.  
  37.    To learn the current status of any Internet-Draft, please check the
  38.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  39.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  40.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  41.    ftp.isi.edu (US West Coast).
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Rosen, et al.                                                   [Page 1]
  54.  
  55.  
  56. Internet Draft        draft-rosen-tag-stack-00.txt         November 1996
  57.  
  58.  
  59.  
  60.  
  61. Contents
  62.  
  63.     1    Introduction  .............................................   2
  64.     1.1  Specification of Requirements  ............................   2
  65.     2    Encoding the Tag Stack  ...................................   3
  66.     3    Transporting Tagged Packets over PPP  .....................   5
  67.     3.1  Introduction  .............................................   5
  68.     3.2  A PPP Network Control Protocol for Tag Switching  .........   6
  69.     3.3  Sending Tagged Packets  ...................................   7
  70.     3.4  Tag Switching Control Protocol Configuration Options  .....   7
  71.     4    Transporting Tagged Packets over LAN Media  ...............   7
  72.     5    Security Considerations  ..................................   8
  73.     6    Authors' Addresses  .......................................   8
  74.     7    References  ...............................................   9
  75.  
  76.  
  77.  
  78.  
  79. 1. Introduction
  80.  
  81.    [1] describes a need to encode a "Tag Stack" into a packet.  This
  82.    document specifies how the Tag Stack is encoded on Tagged Packets
  83.    which are sent over PPP data links and over LAN data links.
  84.  
  85.  
  86. 1.1. Specification of Requirements
  87.  
  88.    In this document, several words are used to signify the requirements
  89.    of the specification.  These words are often capitalized.
  90.  
  91.         MUST
  92.  
  93.         This word, or the adjective "required", means that the
  94.         definition is an absolute requirement of the specification.
  95.  
  96.         MUST NOT
  97.  
  98.         This phrase means that the definition is an absolute prohibition
  99.         of the specification.
  100.  
  101.         SHOULD
  102.  
  103.         This word, or the adjective "recommended", means that there may
  104.         exist valid reasons in particular circumstances to ignore this
  105.         item, but the full implications must be understood and carefully
  106.         weighed before choosing a different course.
  107.  
  108.  
  109.  
  110. Rosen, et al.                                                   [Page 2]
  111.  
  112.  
  113. Internet Draft        draft-rosen-tag-stack-00.txt         November 1996
  114.  
  115.  
  116.         MAY
  117.  
  118.         This word, or the adjective "optional", means that this item is
  119.         one of an allowed set of alternatives.  An implementation which
  120.         does not include this option MUST be prepared to interoperate
  121.         with another implementation which does include the option.
  122.  
  123.  
  124. 2. Encoding the Tag Stack
  125.  
  126.    On both PPP and LAN data links, the Tag Stack is represented as a
  127.    sequence of Tag Stack Entries.  Each Tag Stack Entry is represented
  128.    as a 4-byte quantity.  This is shown in Figure 1.
  129.  
  130.     0                   1                   2                   3
  131.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  132.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tag
  133.    |                Tag                  |rsvd |CoS|S|     TTL     | Stack
  134.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
  135.  
  136.                        Tag:  tag value, 19 bits
  137.                        rsvd: reserved, 3 bits
  138.                        CoS:  Class of Service, 2 bits
  139.                        S:    bottom of stack, 1 bit
  140.                        TTL:  7 bits
  141.  
  142.                                  Figure 1
  143.  
  144.  
  145.    The Tag Stack Entries appear after the end of all data link layer
  146.    headers, but before any network layer headers.  The entry
  147.    representing the top of the Tag Stack appears earliest in the packet.
  148.    The entry representing the bottom of the Tag Stack appears latest.
  149.    The network layer packet immediately follows the Tag Stack Entry with
  150.    the S bit set.
  151.  
  152.    Each Tag Stack Entry is broken down into the following fields:
  153.  
  154.       1. Stack End Bit (S)
  155.  
  156.          This bit is set to one for the last entry in the Tag Stack
  157.          (i.e., for the bottom of the stack), and zero for all other Tag
  158.          Stack Entries.
  159.  
  160.       2. Time to Live (TTL)
  161.  
  162.          This seven-bit field is used to encode a time-to-live value.
  163.  
  164.  
  165.  
  166.  
  167. Rosen, et al.                                                   [Page 3]
  168.  
  169.  
  170. Internet Draft        draft-rosen-tag-stack-00.txt         November 1996
  171.  
  172.  
  173.          When the first tag is pushed onto an untagged IP packet, the
  174.          TTL value in the Tag Stack Entry MUST be set to the smaller of
  175.          127 and the value of the IP TTL field.
  176.  
  177.          At every hop which tag switches a packet, the TTL value of the
  178.          packet's top Tag Stack Entry MUST be decremented by at least 1.
  179.  
  180.          When the Tag Stack is popped, and the resulting Tag Stack is
  181.          non-empty,the TTL value in the new top stack entry MUST be
  182.          decremented by 1.
  183.  
  184.          When the Tag Stack is popped, and the resulting Tag Stack is
  185.          empty, and the network layer packet is an IP packet, the TTL
  186.          value in the IP packet MUST be decremented by at least 1; it
  187.          SHOULD be modified as follows.  If the TTL value in the IP
  188.          packet is less than or equal to 127, it is replaced with the
  189.          TTL value from the last Tag Stack Entry.  If the TTL value in
  190.          the IP packet is greater than 127, it is replaced by the value
  191.          which results from first subtracting the TTL value in the Tag
  192.          Stack Entry from 127, and then subtracting that difference from
  193.          the the TTL value in the IP header.  If this causes the TTL
  194.          value in the IP header to become less than 1, the ordinary
  195.          processing for an IP packet whose TTL has become less than 1
  196.          MUST be performed.
  197.  
  198.          If at any time, the value of the TTL field in a Tag Stack Entry
  199.          becomes less than 1, the packet MUST NOT be forwarded further.
  200.          Depending on the tag value in the Tag Stack Entry, the packet
  201.          may be silently discarded, or the packet may have its Tag Stack
  202.          stripped off, and passed as an untagged packet to the ordinary
  203.          processing for network layer packets which have exceeded their
  204.          maximum lifetime in the network.
  205.  
  206.       3. Class of Service (CoS)
  207.  
  208.          This two-bit field is used to identify a class of service.
  209.  
  210.       4. Reserved
  211.  
  212.          These three bits are reserved.  They MUST be set to zero when
  213.          writing, and MUST be ignored when reading.
  214.  
  215.       5. Tag Value
  216.  
  217.          This 19-bit field carries the actual tag value.
  218.  
  219.          A value of 0 represents the "Explicit NULL Tag".  The presence
  220.          of the Explicit NULL Tag means that the Tag Stack must be
  221.  
  222.  
  223.  
  224. Rosen, et al.                                                   [Page 4]
  225.  
  226.  
  227. Internet Draft        draft-rosen-tag-stack-00.txt         November 1996
  228.  
  229.  
  230.          popped, and the forwarding of the packet must then be based on
  231.          the resulting top tag in the Tag Stack, or, if the Tag Stack
  232.          becomes empty, on the network layer header.
  233.  
  234.  
  235. 3. Transporting Tagged Packets over PPP
  236.  
  237.    The Point-to-Point Protocol (PPP) [PPP] provides a standard method
  238.    for transporting multi-protocol datagrams over point-to-point links.
  239.    PPP defines an extensible Link Control Protocol, and proposes a
  240.    family of Network Control Protocols for establishing and configuring
  241.    different network-layer protocols.
  242.  
  243.    This section defines the Network Control Protocol for establishing
  244.    and configuring Tag Switching over PPP.
  245.  
  246.  
  247. 3.1. Introduction
  248.  
  249.    PPP has three main components:
  250.  
  251.       1. A method for encapsulating multi-protocol datagrams.
  252.  
  253.       2. A Link Control Protocol (LCP) for establishing, configuring,
  254.          and testing the data-link connection.
  255.  
  256.       3. A family of Network Control Protocols for establishing and
  257.          configuring different network-layer protocols.
  258.  
  259.    In order to establish communications over a point-to-point link, each
  260.    end of the PPP link must first send LCP packets to configure and test
  261.    the data link.  After the link has been established and optional
  262.    facilities have been negotiated as needed by the LCP, PPP must send
  263.    Tag Switching Control packets to enable the transmission of tagged
  264.    packets.  Once the Tag Switching Control Protocol has reached the
  265.    Opened state, tagged packets can be sent over the link.
  266.  
  267.    The link will remain configured for communications until explicit LCP
  268.    or Tag Switching Control Protocol packets close the link down, or
  269.    until some external event occurs (an inactivity timer expires or
  270.    network administrator intervention).
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281. Rosen, et al.                                                   [Page 5]
  282.  
  283.  
  284. Internet Draft        draft-rosen-tag-stack-00.txt         November 1996
  285.  
  286.  
  287. 3.2. A PPP Network Control Protocol for Tag Switching
  288.  
  289.    The Tag Switching Control Protocol is responsible for enabling and
  290.    disabling the use of tag switching on a PPP link.  it uses the same
  291.    packet exchange mechanism as the Link Control Protocol (LCP).  Tag
  292.    Switching Control Protocol packets may not be exchanged until PPP has
  293.    reached the Network-Layer Protocol phase.  Tag Switching Control
  294.    Protocol packets received before this phase is reached should be
  295.    silently discarded.
  296.  
  297.    The Tag Switching Control Protocol is exactly the same as the Link
  298.    Control Protocol [1] with the following exceptions:
  299.  
  300.       1. Frame Modifications
  301.  
  302.          The packet may utilize any modifications to the basic frame
  303.          format which have been negotiated during the Link Establishment
  304.          phase.
  305.  
  306.       2. Data Link Layer Protocol Field
  307.  
  308.          Exactly one Tag Switching Control Protocol packet is
  309.          encapsulated in the PPP Information field, where the PPP
  310.          Protocol field indicates type hex 80?? (Tag Switching).
  311.  
  312.       3. Code field
  313.  
  314.          Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  315.          Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
  316.          Ack and Code-Reject) are used.  Other Codes should be treated
  317.          as unrecognized and should result in Code-Rejects.
  318.  
  319.       4. Timeouts
  320.  
  321.          Tag Switching Control Protocol packets may not be exchanged
  322.          until PPP has reached the Network-Layer Protocol phase.  An
  323.          implementation should be prepared to wait for Authentication
  324.          and Link Quality Determination to finish before timing out
  325.          waiting for a Configure-Ack or other response.  It is suggested
  326.          that an implementation give up only after user intervention or
  327.          a configurable amount of time.
  328.  
  329.       5. Configuration Option Types
  330.  
  331.          None.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Rosen, et al.                                                   [Page 6]
  339.  
  340.  
  341. Internet Draft        draft-rosen-tag-stack-00.txt         November 1996
  342.  
  343.  
  344. 3.3. Sending Tagged Packets
  345.  
  346.    Before any tagged packets may be communicated, PPP must reach the
  347.    Network-Layer Protocol phase, and the Tag Switching Control Protocol
  348.    must reach the Opened state.
  349.  
  350.    Exactly one tagged packet is encapsulated in the PPP Information
  351.    field, where the PPP Protocol field indicates either type hex 00??
  352.    (Tag Switching -- Unicast) or type hex 00?? (Tag Switching --
  353.    Multicast).  The maximum length of a tagged packet transmitted over a
  354.    PPP link is the same as the maximum length of the Information field
  355.    of a PPP encapsulated packet.
  356.  
  357.    The format of the Information field itself is as defined in section
  358.    2.
  359.  
  360.    Note that two codepoints are defined for tagged packets; one for
  361.    multicast and one for unicast.  Once the TSCP has reached the Opened
  362.    state, both tag switched multicasts and tag switched unicasts can be
  363.    sent over the PPP link.
  364.  
  365.  
  366. 3.4. Tag Switching Control Protocol Configuration Options
  367.  
  368.    There are no configuration options.
  369.  
  370.  
  371. 4. Transporting Tagged Packets over LAN Media
  372.  
  373.    A pair of two byte ethertype values will be obtained, one
  374.    representing "Tag Switching -- Unicast" and one representing "Tag
  375.    Switching -- Multicast".
  376.  
  377.    These can be used with either the Ethernet encapsulation or the 802.3
  378.    SNAP/SAP encapsulation to carry tagged packets.
  379.  
  380.    Exactly one tagged packet is carried in each frame.
  381.  
  382.    The Tag Stack Entries immediately precede the network layer header,
  383.    and follow any data link layer headers, including any VLAN headers
  384.    that may exist.
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395. Rosen, et al.                                                   [Page 7]
  396.  
  397.  
  398. Internet Draft        draft-rosen-tag-stack-00.txt         November 1996
  399.  
  400.  
  401. 5. Security Considerations
  402.  
  403.    Security considerations are not discussed in this document.
  404.  
  405.  
  406. 6. Authors' Addresses
  407.  
  408.    Eric C. Rosen
  409.    Cisco Systems, Inc.
  410.    250 Apollo Drive
  411.    Chelmsford, MA, 01824
  412.  
  413.    E-mail: erosen@cisco.com
  414.  
  415.  
  416.    Dan Tappan
  417.    Cisco Systems, Inc.
  418.    250 Apollo Drive
  419.    Chelmsford, MA, 01824
  420.  
  421.    E-mail: tappan@cisco.com
  422.  
  423.    Dino Farinacci
  424.    Cisco Systems, Inc.
  425.    170 Tasman Drive
  426.    San Jose, CA, 95134
  427.  
  428.    E-mail: dino@cisco.com
  429.  
  430.    Yakov Rekhter
  431.    Cisco Systems, Inc.
  432.    170 Tasman Drive
  433.    San Jose, CA, 95134
  434.  
  435.    E-mail: yakov@cisco.com
  436.  
  437.    Guy Fedorkow
  438.    Cisco Systems, Inc.
  439.    250 Apollo Drive
  440.    Chelmsford, MA, 01824
  441.  
  442.    E-mail: fedorkow@cisco.com
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452. Rosen, et al.                                                   [Page 8]
  453.  
  454.  
  455. Internet Draft        draft-rosen-tag-stack-00.txt         November 1996
  456.  
  457.  
  458. 7. References
  459.  
  460.    [1] Tag Switching Architecture Overview, draft-rfced-info-rekhter-
  461.    00.txt, Rekhter, Davie, Katz, Rosen, Swallow
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509. Rosen, et al.                                                   [Page 9]
  510.