Network Working Group                                   Fred Baker
Internet Draft                                       Cisco Systems
Expiration Date: April 1997                          Yakov Rekhter
                                                     Cisco Systems


                  Use of Flow Label for Tag Switching

                     draft-baker-flow-label-00.txt


1. 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).


2. Abstract

   An overview of a tag switching architecture is provided in [tag-
   arch].  This document proposes to extend the syntax and semantics of
   the Flow Label field in the IPv6 header to facilitate IPv6 forwarding
   by allowing the Flow Label field to carry tag information.















Fred Baker, Yakov Rekhter                                       [Page 1]





Internet Draft       draft-baker-flow-label-00.txt          October 1996


3. Description

   A tag switching architecture is described in [tag-arch].  This
   document proposes to use the Flow Label field in the IPv6 header
   [RFC1883] as a mechanism for tag switching with IPv6. With this
   proposal the Flow Label field is used to carry the tag information
   (tag).

   This document doesn't constrain the forwarding granularity associated
   with a tag that could be carried in the Flow Label field. For
   example, it is expected that a tag could be associated either with a
   group of routes (group of address prefixes), or with a multicast tree
   (either shared or source-based), or with an individual flow.

   A router determines whether the Flow Label field carries a tag by
   examining the high-order bit of the Flow Label field.  If the most
   significant bit is zero and the lower order 23 bits are not, it is
   presumed to be a flow label (as defined in [RFC1883]).  If the high-
   order bit is 1, it is assumed to be a tag.


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Prio. |G|                 Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Prio.                4-bit priority value.

       G                  G=0 indicates global end-to-end flow label definition,
                          G=1 indicates hop-by-hop flow label definition (tag).


       Flow Label           23-bit flow label.


   A router could place a tag into the Flow Label field of a packet only
   if the Flow Label field is all zeros (this restriction doesn't apply
   to the case where a router just replaces one tag with another).

   If a router is not capable of using a tag, and the router receives an
   IPv6 packet that carries a tag, the router forwards the packet
   following the normal IPv6 procedures.










Fred Baker, Yakov Rekhter                                       [Page 2]





Internet Draft       draft-baker-flow-label-00.txt          October 1996


4. Differences with the current definition of Flow Labels

   With this proposal the Flow Label field could be modified at every
   hop.  This is in contrast with the current definition of Flow Label
   [RFC1883], where the value of this field is set up by the source of a
   packet, and is not modified by the routers that forward the packet.
   Moreover, the semantics of tag is different from the semantics of the
   Flow Label, as packets carrying the same tag may come from more than
   one source.

   We propose to reserve the value of the high-order bit of the Flow
   Label field to 1 (binary) to identify the cases where the field
   carries a tag.

   Use of the Flow Label field to carry a tag would require changes to
   the Authentication Header as used by IPv6, as it currently requires
   inclusion of the Flow Label field in the data certified by the
   digest.


5. Security Considerations

   Security issues are not discussed in this document.


6. Acknowledgements

   To be supplied.


7. References

   [RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
   (IPv6) Specification", RFC1883, December 1995

   [tag-arch] Rekhter, Y., Davie, B., Katz, D., Rosen, E., Swallow, G.,
   "Tag Switching Architecture", draft-rfced-info-rekhter-00.txt,
   Internet Draft, September 1996













Fred Baker, Yakov Rekhter                                       [Page 3]





Internet Draft       draft-baker-flow-label-00.txt          October 1996


8. Author Information


   Fred Baker
   cisco Systems, Inc.
   170 Tasman Dr.
   San Jose, CA 95134
   Phone: (408) 526-4257
   email: fred@cisco.com

   Yakov Rekhter
   cisco Systems, Inc.
   170 Tasman Dr.
   San Jose, CA 95134
   Phone: (914) 528-0090
   email: yakov@cisco.com



































Fred Baker, Yakov Rekhter                                       [Page 4]