(sipp) Submitted ID: SDRP Routing Header Format for SIPP-16

"Peter S. Ford" <peter@goshawk.lanl.gov> Thu, 21 July 1994 19:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18437; 21 Jul 94 15:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18429; 21 Jul 94 15:06 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa20840; 21 Jul 94 15:06 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14737; Thu, 21 Jul 94 12:02:14 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09388; Thu, 21 Jul 94 12:03:13 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01335; Thu, 21 Jul 94 12:03:45 PDT
Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA01329; Thu, 21 Jul 94 12:03:38 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA25158; Thu, 21 Jul 94 12:01:14 PDT
Received: from goshawk.lanl.gov by Sun.COM (sun-barr.Sun.COM) id AA12721; Thu, 21 Jul 94 11:54:25 PDT
Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.9/8.6.4) with SMTP id LAA22934; Thu, 21 Jul 1994 11:40:43 -0600
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Peter S. Ford" <peter@goshawk.lanl.gov>
Message-Id: <199407211740.LAA22934@goshawk.lanl.gov>
X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol
To: sipp@sunroof.eng.sun.com, sdrp@catarina.usc.edu
Subject: (sipp) Submitted ID: SDRP Routing Header Format for SIPP-16
Date: Thu, 21 Jul 1994 11:40:42 -0700
X-Orig-Sender: owner-sipp@sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp@sunroof.eng.sun.com

Per the last round of discussion on source routing functionality we 
have submitted the following to the ID directories.

peter
>>> Cut Here
                           - 1 -



Network Working Group                                        Peter Ford
INTERNET DRAFT                                                     LANL
                                                                Tony Li
                                                          cisco Systems
                                                          Yakov Rekhter
                                  T.J. Watson Research Center, IBM Corp.
                                                               July 1994


                 SDRP Routing Header Format for SIPP-16


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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.


1. Introduction


   This document specifies the format of a SIPP extended routing header
   to provide forwarding functionality comparable to SDRP [SDRP].  The
   reader should be familiar with [SIPP-16].


2. Acknowledgements


   This document is based on "Source Demand Routing: Packet Format and
   Forwarding Specification (Version 1)" [SDRP].


3.  Model of Operation



   An Internet can be viewed as a collection of routing domains





Expiration Date January 1995                                    [Page 1]

                           - 2 -



   interconnected by means of common subnetworks, and Border Routers
   (BRs) attached to these subnetworks.  A routing domain itself may be
   composed of further subnetworks, routers interconnecting these
   subnetworks, and hosts.  This document assumes that there is some
   type of routing present within the routing domain, but it does not
   assume that this intra-domain routing is coordinated or even
   consistent.

   For the purposes of this discussion, a BR belongs to only one domain.
   A pair of BRs, each belonging to a different domain, but attached to
   a common subnetwork, form an inter-domain connection. By definition,
   packets that traverse multiple domains must traverse BRs of these
   domains.  Note that a single physical router may act as multiple BRs
   for the purposes of this model.

   A pair of domains is said to be adjacent if there is at least one
   pair of BRs, one in each domain, that form an inter-domain
   connection.

   Each domain has a globally unique identifier, called a Domain
   Identifier (DI). All the BRs within a domain need to know the DI
   assigned to the domain.  Management of the DI space is outside the
   scope of this document.  This document assumes that DIs are expressed
   as SIPP-16 cluster addresses.  A domain path (or simply path) refers
   to a list of DIs such as might be taken from an IDRP RD path.

   A component in an SDRP route is either a DI (expressed as a cluster
   address) or a router (expressed as a unicast address).  Thus, an SDRP
   route is defined as a sequence of domains and routers, syntactically
   expressed as a sequence of cluster and unicast addresses.  Thus an
   SDRP route is a collection of source routed hops.

   An SDRP hop can either be a "strict" source routed hop, or a "loose"
   source routed hop.  A strict source route hop is one in which, if the
   next hop specified is a DI, and the DI refers to a domain immediately
   adjacent to the current domain, then the packet will be forwarded
   directly along a route within the domain; if the next hop specified
   is an IP address, then it must refer to an immediately adjacent
   system on a common subnetwork to the current router.  Any other kind
   of a source route hop is a loose source route hop.

   A route is a "strict source route" if the current hop being executed
   is processed as a strict source route hop.  Likewise, a route is a
   "loose source route" if the current hop being executed is processed
   as a loose source route hop.

   In the common case of unicast source routing, the last element of a
   source route will be the unicast address of the destination host.  A
   source route with components consisting of a list of DIs  terminated
   by a unicast destination address would be used for implementing
   provider selection to a destination.





Expiration Date January 1995                                    [Page 2]

                           - 3 -



   This document specifies SDRP operations when that common network
   layer protocol is [SIPP-16].


4. SDRP Routing Header format


   A SDRP Routing Header is a type of a SIPP Routing Header. The value
   of the Routing Type field of the SIPP Routing Header is set to 1 for
   a SDRP Routing Header.  A SDRP SIPP-16 Routing header has the
   following format:



          0                   1                   2                   3
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Next Header   |Routing Type=1 |M|F| Reserved   | SrcRouteLen  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | NextHopPtr    |            Strict/Loose Bit Mask              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |        Source Route, a list of SIPP addresses                 |
         |        (integral multiple of 128 bits)                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Next Header - 8-bit selector. Identifies the type of the header
      immediately following the Routing header.  Uses the same values as
      the IPv4 Protocol field [RFC-1340] plus new types defined for
      SIPP.

      Routing Type - 1.

      Flags (2 bits):

          MRE, Must Report Errors (bit 0).

              If this bit is set to 1, and a router can not further
              forward a packet (with an incompletely traversed source
              route), as specified in the Source Route, the router must
              generate an ICMP error message. If this bit is set to 0,
              and a router can not further forward a packet (with an
              incompletely traversed source route), as specified in the
              Source Route, the router should not generate an ICMP error
              message.

          Failure of Source Route Behavior(bit 1).

              If this bit it set to 1, it indicates that if a router can
              not further forward a packet (with an incompletely
              traversed source route), as specified in the Source Route,





Expiration Date January 1995                                    [Page 3]

                           - 4 -



              the router must set the value of the Next Hop Pointer
              field to the value of the Source Route Length field, so
              that the subsequent forwarding will be based solely on the
              destination address. If this bit is set to 0, it indicates
              that if a router can not further forward a packet (with an
              incompletely traversed source route), as specified in the
              Source Route, the router must discard the packet.

      Reserved (6 bits).

              Must be sent as zero and ignored on receipt.

      Source Route Length- 8 bit unsigned integer.  Number of source
      route elements/hops in the SDRP Routing header.  Length of SDRP
      routing header can be calculated from this value (length =
      SrcRouteLen * 16 + 8) This field may not exceed a value of 24.


      Next Hop Pointer- 8 bit unsigned integer.  Index of next
      element/hop to be processed; initialized to 0 to point to first
      element/hop in the source route.  When Next Hop Pointer is equal
      to Source Route Length then the Source Route is completed.

      Strict/Loose Bit Mask (24 bits).

              The Strict/Loose Bit Mask is used when making a forwarding
              decision. If the value of the Next Hop Pointer field is N,
              and the N-th bit in the Strict/Loose Bit Mask field is set
              to 1, it indicates that the next hop is a Strict Source
              Route Hop. If this bit is set to 0, it indicates that the
              next hop is a Loose Source Route Hop.

      Source Route (variable length, multiple of 16 octets).

              The components of the source route are syntactically
              SIPP-16 addresses[SIPP-16]. A Source Route can contain an
              arbitrary intermix of unicast and cluster addresses.


5. Forwarding Behavior

The forwarding behavior is defined in [SRFSS].


6. Authors' Address


   Peter Ford
   Los Alamos National Laboratory
   Los Alamos
   Phone: (505) 665-0058





Expiration Date January 1995                                    [Page 4]

                           - 5 -



   e-mail: peter@goshawk.lanl.gov

   Tony Li
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025
   email: tli@cisco.com

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY 10598
   Phone:  (914) 945-3896
   email:  yakov@watson.ibm.com


7. References


[RFC-1340] Reynolds, J. and Postel, J. "Assigned Numbers".  July 1992.
RFC 1340.


[SDRP] Estrin, D., Li, T. , Rekhter, Y., and Varadhan K., "Source Demand
Routing: Packet Format and Forwarding Specification (Version 1)"   22
March, 1994. Internet Draft.


[SIPP-16] Deering, S., "Simple Internet Protocol Plus (SIPP)
Specification (128 bit address version)". 17 July 1994. Internet Draft.


[SRFSS] Li, T., Rekhter, Y. and Ford, P. "Source Routing Forwarding
Specification for SIPP".  Work in Progress.






















Expiration Date January 1995                                    [Page 5]

 ------------------------------------------------------------------------------
IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to majordomo@sunroof.eng.sun.com