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

Christian Huitema <Christian.Huitema@sophia.inria.fr> Fri, 22 July 1994 08:00 UTC

Message-Id: <199407220801.AA10941@mitsou.inria.fr>
To: sipp@sunroof.eng.sun.com
Cc: sdrp@catarina.usc.edu
Subject: Re: (sipp) Submitted ID: SDRP Routing Header Format for SIPP-16
In-Reply-To: Your message of "Thu, 21 Jul 1994 11:40:42 MST." <199407211740.LAA22934@goshawk.lanl.gov>
Date: Fri, 22 Jul 1994 10:01:28 +0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Christian Huitema <Christian.Huitema@sophia.inria.fr>
Precedence: bulk
Reply-To: sipp@sunroof.eng.sun.com

Peter, Tony, Yakov,

This is a very interesting contribution. I wait to see the details of your
forwarding specification - we should check the consistency with the general
sipp-16 routing document.

I see however one minor problem - gratuitous change in the header format. If
we compare what you propose: 

=>    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)                        |
=>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=> 

With the existing spec:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |  Routing Type |   Num Addrs   |   Next Addr   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Reserved                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |

one really wonders why you did not simply used the 32 bits reserved field for
the "routing type = 1" specific fields, which would give something like:

          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 |  SrcRouteLen  |  NextHopPtr   | 
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |M|F| Reserved  |            Strict/Loose Bit Mask              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

thus providing a very simple incorporation in the existing SIPP-16 specs - the
only difference between routing type 0 and routing type 1 being "policy
enforcement".

Christian Huitema
 ------------------------------------------------------------------------------
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

(sipp) Submitted ID: SDRP Routing Header Format f… Peter S. Ford
(sipp) Submitted ID: SDRP Routing Header Format f… Deborah Estrin
Re: (sipp) Submitted ID: SDRP Routing Header Form… Christian Huitema