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]