[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
                                                 S. Deering (Xerox PARC)
                                                   P. Francis (Bellcore)
                                                  R. Govindan (Bellcore)
                                                            October 1993


                 Simple Internet Protocol Plus (SIPP):
          Overview of Routing and Addressing Extensions to SIP


Status of the 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 I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any
other Internet Draft.


1.  INTRODUCTION

   The Simple Internet Protocol Plus (SIPP) retains most of the simpli-
   city of SIP [1], while adding some of the features provided by Pip
   [2].  Specifically, SIPP uses the same syntax as SIP, but the use of
   the SIP Routing Header (an option similar to the loose source route
   option of IP) has been enhanced to enable the features provided by
   the Pip FTIF Chain style of routing.

   This document primarily describes the additions to SIP that enable
   provider selection, mobility, auto-configuration, and variable-length
   addressing.  Thus, this document targets those people who already
   understand SIP, and wish to understand what additional features come
   with SIPP.  A future document will provide a complete description of
   SIPP routing and addressing.

   The authors would like to acknowledge the contributions of Bob Gilli-
   gan (Sun), Bob Hinden (Sun), Christian Huitema (INRIA), and Erik
   Nordmark (Sun).


1.1.  Terminology

   The terminology defined in the SIPP Specification [8] applies to this
   document.  The first three terms below are copied from [8] for clar-
   ity.  The following additional terminology is defined below that:

   address: A 64-bit SIPP layer identifier for a node or set of nodes.
            An address can be used for both routing and identification
            purposes.

   uniqueness scope: The topologically defined region over which an
            address may be assigned to no more than one node or set
            of nodes.

   routing scope: The topologically defined region over which hosts
            and routers have sufficient routing information to forward



SIP WG, Expires April 1, 1994                                  [Page 1]


                    draft-ietf-sip-overview-00.txt         October 1993


            a packet toward the node(s) identified by that address.

   route sequence: The sequence of addresses consisting of the source
            address, the destination address, and the addresses encoded
            in the optional Routing Header of the SIPP packet.

   address sequence: A sequence of addresses that forms part of the
            route sequence.  The address sequence is used for the
            purpose of routing to a node in the case where a single
            (64-bit) address has insufficient routing scope.

   identifying address: The low-order address in an address sequence.
            Of the addresses in an address sequence, only the
            identifying address is used to identify the source and
            destination of a packet (for instance, by the transport
            protocol).


2.  SIPP ADDRESSING

   A SIPP address serves two purposes.  One is to uniquely identify the
   node (or set of nodes) to which the address belongs.  The other is to
   specify the location of the addressed node(s) in the internet topol-
   ogy, to facilitate routing.

   SIPP addresses are unlike IP addresses (and similar to OSI NSAP [9]
   addresses) in that they identify nodes (i.e., hosts or routers)
   rather than interfaces.  This having been said, it is possible to
   assign SIPP address prefixes on a per-interface basis, with the
   result that packets to a node will tend to arrive over the interface
   from which the node's address was derived.

   A SIPP address is said to have a certain "routing scope", which is
   the topological region over which nodes have sufficient routing
   information to deliver a packet to the node(s) identified by that
   address.  Most SIPP addresses have global routing scope, meaning they
   are routable from anywhere in the internet.  However, some addresses
   have less than global routing scope.  For example, during bootstrap-
   ping a SIPP node may use an address derived from its link-level
   address (e.g., an Ethernet address) that is only locally routable.

   Every SIPP packet contains two Identifying Addresses (IADs), identi-
   fying the source and destination nodes of the packet.  The
   transport-layer pseudo-header checksum for the packet is calculated
   using the two IADs.

   The two IADs may or may not contain sufficient location information
   to route the packet to its destination(s) (or to route an error



SIP WG, Expires April 1, 1994                                  [Page 2]


                    draft-ietf-sip-overview-00.txt         October 1993


   message back to its source).  When they are insufficient, an optional
   SIPP Routing Header is included in the packet to carry the additional
   addressing information required for routing.  These additional
   addresses may be viewed as high-order extensions of the IADs.  The
   additional addresses and the IAD, taken together, are called an
   address sequence.

   For instance, an address sequence can be used for a mobile node that
   is attached to a place in the internet other than the location speci-
   fied by its IAD.  Or, an address sequence can be used if the routing
   scope of the IAD is not sufficient (as may happen if the internet
   grows too large to assign globally-routable addresses to all nodes).
   This way, the address sequence can be used to achieve the effect of a
   variable length address.  Even when the address sequence is used to
   extend the address length beyond 64 bits, however, the identification
   function uses only the "low order" 64 bits (the IAD).


2.1.  Unicast Addresses

   The SIPP unicast address or address sequence is contiguous bit-wise
   maskable, similar to IP addresses under CIDR [3].

   The use of the optional Routing Header mechanism as the means of
   hierarchically extending SIPP addresses puts some constraints on the
   assignment and use of SIPP unicast addresses.

   First, since the Routing Header mechanism only allows a route to
   examine 64 bits at a time, a single "hierarchy element" from a SIPP
   hierarchical unicast address sequence cannot straddle a 64-bit boun-
   dary.

   Second, when using a 128-bit address sequence, both the low and high
   order 64 bits must individually be globally unique.  (If the address
   sequence is greater than 128 bits, the middle 64-bit addresses may
   not have to be globally unique.  In the event that SIPP address
   sequences grow beyond 128 bits, this possibility can be considered.)

   Third, routing must be configured such that, once a given 64-bit seg-
   ment of an address sequence is examined by a router for the purpose
   of forwarding a packet, previous (higher order) 64-bit addresses can-
   not subsequently be used as part of the forwarding decision.  In
   other words, once the Routing Header is advanced to a certain 64-bit
   address, previous addresses cannot be examined.  This places a minor
   constraint on routing's ability to selectively "look into" other
   parts of the hierarchy.





SIP WG, Expires April 1, 1994                                  [Page 3]


                    draft-ietf-sip-overview-00.txt         October 1993


2.1.1.  Unicast Address Assignment

   There are several forms of unicast address assignment in SIPP,
   including the global hierarchical unicast address, the cluster
   address, and the local-use address.  The global unicast address is
   initially assigned as follows:

     |1|      n bits       |        m bits       |   p bits  | 63-n-m-p|
     +-+-------------------+---------------------+-----------+---------+
     |C|    provider ID    |    subscriber ID    | subnet ID | node ID |
     +-+-------------------+---------------------+-----------+---------+

   The first bit is the IP compatibility bit, or C-bit [6].  It indi-
   cates if the node represented by the address is IP-only or SIPP [8].

   SIPP addresses are provider-oriented.  That is, the high-order part
   of the address is assigned to providers, which then assign portions
   of the address space to subscribers, etc.  This is similar to assign-
   ment of IP addresses under the CIDR scheme [3].  The provider ID
   numbers are assigned in such a way that an additional layer of
   hierarchy can be added above or below the provider ID layer.  The
   node ID corresponds to IP's host number.

   Appendix A gives more details of the proposed approach to SIPP global
   unicast address assignment.

2.1.2.  Cluster Addresses

   Cluster addresses are a special form of unicast address that allows a
   packet to be sent to one of multiple destinations (this type of
   delivery service is sometimes called anycast).  Cluster addresses are
   of the form <prefix><zero>.  Cluster addresses allow a packet to be
   sent to the "nearest" node (according to unicast routing's notion of
   nearest) of a group of nodes.  The purpose of a cluster address is to
   be able to route a packet to one of a group of nodes characterized by
   sharing a certain prefix in the unicast global hierarchical address
   space.

   When the packet is being sent from "outside" the group of nodes (that
   is, being transmitted by a node that has no prefix in common with the
   cluster address), the resulting behaviour is that the packet is
   accepted by the first router whose own address prefix matches the
   prefix in the cluster address.  When the packet is being sent from
   "within" the group of nodes (that is, being transmitted by a node
   whose own address prefix matches that of the cluster address), the
   resulting behaviour is that the packet is transmitted up the hierar-
   chy until it reaches a router that is acting "at the hierarchy level"
   of the prefix.



SIP WG, Expires April 1, 1994                                  [Page 4]


                    draft-ietf-sip-overview-00.txt         October 1993


   The SIPP routing and addressing specification will contain a precise
   and general definition of which nodes get assigned which cluster
   addresses.  However, in the context of the initial format of SIPP
   hierarchical unicast address, the following cluster addresses are
   defined:

   Provider.0
        Routers that comprise the provider's network (that is, not
        comprising subscriber networks attached to the provider) identi-
        fied by the Provider ID are assigned these cluster addresses.

   Provider.Subscriber.0
        Routers whose addresses match with Provider.Subscriber, and that
        share a link with routers that have cluster address Provider.0
        are assigned these cluster addresses.

   Provider.Subscriber.Subnet.0
        Routers whose addresses match with Provider.Subscriber.Subnet,
        and that share a link with routers that have cluster address
        Provider.Subscriber.0 are assigned these cluster addresses.

   Packets with address Provider.0 will be accepted by the first router
   belonging to the indicated provider.  This cluster address is used
   for provider selection and for forming provider-level policy routes.

   Packets with address Provider.Subscriber.Subnet.0 will be accepted by
   the first router in the indicated subnet.  This cluster address is
   useful for auto-configuration and for mobile hosts where the scope of
   mobility is the subnet.  If the scope of mobility is the subscriber
   network, then the cluster address Provider.Subscriber.0 can be used.

   The routing and addressing specification will describe how a host
   learns the various cluster addresses.

2.1.3.  Local-Use Address

   A SIPP node can form a SIPP address from its own link address (for
   instance, its Ethernet address).  This address is only guaranteed to
   be unique on the local link (from which the link address was
   derived).  The link address can be used for local communication in a
   site, for instance for networks that are not connected to the inter-
   net, or temporarily for auto-configuration purposes.

   Local-Use Addresses have the following format:







SIP WG, Expires April 1, 1994                                  [Page 5]


                    draft-ietf-sip-overview-00.txt         October 1993


    | 8 bits | 8 bits  |                  48 bits                    |
    +--------+---------+---------------------------------------------+
    |01111101|subnet ID|                link address                 |
    +--------+---------+---------------------------------------------+

   If the link address is less than 48 bits, then it is positioned at
   the low-order portion of the link address field and padded with
   zeros.  If the subnet ID is unknown (for instance, because there is
   no router on the subnet), then the subnet ID is set to all zeros.


2.2.  Other Address Formats

   The other address formats described in [8] (Multicast, Unspecified,
   Loopback, Reserved Multicast, All Nodes, All Hosts, and All Routers
   Addresses) are as specified in [8].

3.  ADDRESS SEQUENCE HANDLING BY NODES

   For address sequences to be an effective means of extending SIPP
   addresses or enriching SIPP routing semantics for use in provider
   selection, mobility, auto-readdressing, etc., nodes must be able to
   manipulate address sequences appropriately.  A node must be able to
   recognize that its own addresses and other nodes' addresses may be
   represented as address sequences, for instance in transmitted and
   received packets and in DNS.  A node must also be able to reverse
   address sequences for sending return packets.

3.1.  Address Sequence Notation

   The SIPP mechanism for encoding address sequences is the optional
   Routing Header.  With this mechanism, the active address of the
   optional Routing Header is in the destination address field of the
   SIPP header, and the remaining addresses in the address sequence
   (those that were previously active and those that will be active) are
   in the Routing Header.  Thus, the fields of the Routing Header rotate
   through the destination address field as each becomes active.

   Notated literally, the mechanism would look like this:

                source address   dest address   Routing Header
                --------------   ------------   ------------
     initial          S               A          >B  D
        next          S               B           A >D
       final          S               D           A  B >

   This shows a packet from S, routed through A and B on its way to D.
   The '>' symbol indicates which field is next in the Routing Header



SIP WG, Expires April 1, 1994                                  [Page 6]


                    draft-ietf-sip-overview-00.txt         October 1993


   (i.e., the field pointed to by the Next Addr field of the Routing
   Header).  While this notation accurately depicts what happens in the
   packet header, it is unwieldy, so the following equivalent notation
   is used instead:

     initial     S,*A, B, D
        next     S, A,*B, D
       final     S, A, B,*D

   In this notation, the first element is in the source address field of
   the SIPP header.  The '*' denotes the active element of the Routing
   Header, which is in the destination address field.  The remaining
   elements are in the Routing Header, with the Next Addr field pointing
   to the element after the active one.  This notation is easier to
   read, and not incidentally very similar to the Pip notation, thus
   illustrating that the original SIP Source Routing Header is semanti-
   cally similar to the Pip FTIF Chain.

3.2.  Node Formation of Address Sequences

   This section describes a simple set of rules for the handling of
   address sequences.  These rules allow nodes to form and transmit SIPP
   packets with traditional IP address semantics.  More importantly,
   they allow nodes to receive and "reverse" SIPP packets with advanced
   routing and addressing semantics, such as policy routing.  Thus nodes
   that do not understand advanced routing semantics can still operate
   appropriately when receiving packets from a node that does.

   Every node has a set of address sequences that it considers its own.
   These address sequences are a series of 64-bit addresses of the form
   <Si, Si-1, Si-2, ..., S0>, where S0 is the low-order address and also
   the IAD, and Si is the high-order address.  Note that the terms low-
   order and high-order do not necessarily indicate that the high-order
   terms are hierarchically above the low-order terms.  Rather, the
   implication is that the high-order terms must come first in an
   address sequence.

      [ Note that, for the purpose of allowing simple implementations,
      an address sequence of three addresses is considered sufficient to
      encode a node's source address for any reasonable forseeable
      requirement. ]

   An address sequence of a node constitutes the sum total of informa-
   tion needed in the packet header to route the packet to that node.
   Only the low-order address is required to identify the node.  Some of
   a node's address sequences are source-capable and others are not.  A
   source-capable address sequence is one that can validly be used as a
   "source address" in a transmitted packet.  For instance, unicast



SIP WG, Expires April 1, 1994                                  [Page 7]


                    draft-ietf-sip-overview-00.txt         October 1993


   address sequences are source-capable and multicast address sequences
   are not, though both can be considered by the node to be its own
   address sequences.

   A route sequence may contain a number of components, such as a source
   address sequence, a destination address sequence, a policy route, a
   mobile host base station, or a multicast tree core address.  From the
   perspective of a "simple" node, however, a route sequence contains
   only two parts, the source address sequence and the destination
   address sequence:

           <S0, S1, ..., Si, Dj, Dj-1, ..., D0>

   For a transmitted packet, the source address sequence is one of the
   node's own source-capable address sequences, and the destination
   address sequence is everything else.  For a received packet, the des-
   tination address sequence is (or at least should be) any of the
   node's own address sequences, and the source address sequence is
   everything else.

   In an address sequence, the addresses of the source address sequence
   are ordered with the "low order" parts first, while the addresses of
   the destination address sequence are ordered in the opposite direc-
   tion, with the "high-order" parts first.  Thus the first and last
   addresses are always the identifying addresses--the "low order" parts
   of the source and destination address sequences.

   In the common case with a single-component source and destination
   address, the complete route sequence simply has the form: <S0, D0>.
   Such packets contain no Routing Header.

   When a node has an "association" with another node (that is, a tran-
   sport connection or an application "connection" running over UDP), it
   must maintain the following information with respect to the
   correspondent node (the node with which it has the association):

   1.   The source and destination IADs for the entire association.

   2.   The source and destination address sequences currently in use.

   The low-order parts of the source and destination address sequences
   must match the IADs.

   When a node initiates an association, it will normally learn the des-
   tination address sequence through DNS or from local means (for
   instance, the user typing it in).  It extracts the destination IAD
   for the association from the low-order part of the destination
   address sequence.  It chooses from among its source-capable address



SIP WG, Expires April 1, 1994                                  [Page 8]


                    draft-ietf-sip-overview-00.txt         October 1993


   sequences for the source address sequence, and forms the header as
   indicated above.

   When a node is not the initiator of an association, it must extract
   the appropriate information from the received packet.  A node can
   isolate its own address sequence from the received route sequence by
   matching the tail of the route sequence against its own address
   sequences.  (Note that the multicast groups that the node belongs to
   are included in its list of address sequences for this isolation pro-
   cess.) Once the node isolates its own address sequence from the route
   sequence, what remains is the address sequence of the correspondent
   node.

   Thus, to return a received packet to the correspondent node, the
   node:

   1.   strips off and stores its own address sequence from the tail of
        the route sequence of the received packet,

   2.   reverses the order of the remaining elements of the route
        sequence, and places them on the tail of the route sequence of
        the returned packet,

   3.   prepends a valid source-capable address sequence to the route
        sequence, and

   4.   sets the active address (that is, the address to which the Next
        Addr field of the Routing Header points) to be the first address
        of the destination address sequence.

   If the node's own address sequence in the received packet is source-
   capable, then the transmitted (source) IAD must match that of the
   received (destination) IAD, and the transmitted address sequence
   should match that of the received address sequence.

   Every node must implement these reversal rules.  Even if a node has
   no notion of, say, provider selection, it will successfully return
   packets to a node that does if it implements these rules.

3.3.  Application Handling of SIPP Addresses

   The exact nature of the interface between the SIPP layer and higher
   layer protocols is still an open issue.  At a minimum, an application
   interface that requires only the source and destination IAD must
   exist.  This allows for a simple interface, but limits the control
   that the application has over routing.

   It should also be possible for an application to control the complete



SIP WG, Expires April 1, 1994                                  [Page 9]


                    draft-ietf-sip-overview-00.txt         October 1993


   route sequence if desired.  The details of such an interface are
   under study.

4.  ROUTING ALGORITHMS

   Initially, SIPP routing algorithms will be virtually identical to
   those used with the CIDR version of IP, except that the address used
   will be 64 bits rather than 32.  Over the near term, cluster
   addresses can be configured into routers along with their native
   addresses, and advertised in the normal way.  Eventually it would be
   desirable to have routers automatically determine their own cluster
   addresses.

   If it ever becomes necessary to extend SIPP addresses beyond 64 bits,
   then the routing algorithms can be modified if necessary to reflect
   that change.  (Note that it is not clear that routing algorithms
   would have to be modified for this.)

5.  UNICAST EXAMPLES

   In this section, we give several typical unicast examples that demon-
   strate the use of the Routing Header mechanism for provider selection
   and address extension.  Later sections give typical examples for
   mobility, multicast, and auto-configuration.  A forthcoming full
   specification of SIPP routing and addressing will describe the use of
   the Routing Header mechanism more thoroughly.

   The examples assume the following topology.  Domain D contains node
   H.  Domain E contains node I.  Domain D is attached to providers P
   and Q.  Domain E is attached to providers Q and R.

5.1.  Simple (Non-Extended) Addresses

   Assume that the addresses of node H are P.D.H and Q.D.H, and the
   addresses of node I are Q.E.I and R.E.I, where the notation "a.b.c"
   represents a 64-bit SIPP address.  (Note that the 'D' of P.D.H and
   Q.D.H are subscriber numbers assigned by P and Q respectively, and
   are therefore in general not the same value.) H initiates an associa-
   tion with I by querying DNS and learning the two addresses for I.
   Assume that H chooses Q.E.I, since it has the best "match" with its
   own addresses.  H forms the following packet:

        Route sequence at sender H: Q.D.H, *Q.E.I

   I receives this packet, reverses the (in this case simple) route
   sequence, and returns:

        Reversed route sequence at receiver I: Q.E.I, *Q.D.H



SIP WG, Expires April 1, 1994                                 [Page 10]


                    draft-ietf-sip-overview-00.txt         October 1993


5.2.  Simple Addresses with Provider Selection

   The previous example is in fact a form of provider selection, but it
   is simple in that both ends have the same provider, so nothing expli-
   cit has to be done.  Assume in this case, however, that H wishes to
   send its packet through provider P.  Since I is not attached to pro-
   vider P, H must explicitly indicate that it wants its packet to go
   through provider P, and therefore forms the following packet:

        Route sequence at sender H: P.D.H, *P.0, Q.E.I

   The active element of the route sequence is the cluster address of
   provider P.  This causes routers in domain D to route the packet to
   provider P.  When the first router in provider P receives this
   packet, it recognizes the packet as being for "itself", and advances
   the Routing Header, producing:

        Advanced route sequence at provider P router: P.D.H, P.0, *Q.E.I

   which causes the packet to be routed to I.  Upon receiving this
   packet, I uses the reversing rules stated above, producing the fol-
   lowing packet:

        Reversed route sequence at receiver I: Q.E.I, *P.0, P.D.H

   This packet has a couple of noteworthy characteristics.  First, the
   packet may exit domain E via either provider Q or R, depending on
   what routing considers the best path to provider P.  Second, the P.0
   element is redundant, since the destination address P.D.H will also
   cause the packet to be routed to P.  However, without knowing the
   provider mask of P, I has know way of knowing that P.0 is redundant
   with P.D.H, and so includes both elements.  In the future, it may be
   possible for I to learn H's cluster address and optimize the header
   accordingly.

   To continue this example, assume that I does care which exit provider
   is used to reach H, and further that I chooses provider Q.  In this
   case, I would insert the following "policy route" (actually, one
   address) to force the packet to go through Q outgoing:

        Alternative reversed route sequence:  Q.E.I, *Q.0, P.0, P.D.H

   Note that this example describes a node that is more sophisticated
   than the simple one described previously.  In particular, the node in
   this example understands three components of the source route (the
   source and destination addresses and a provider) rather than just two
   (the source and destination addresses).  The node further understands
   that when it inserts the provider selector in the route sequence, it



SIP WG, Expires April 1, 1994                                 [Page 11]


                    draft-ietf-sip-overview-00.txt         October 1993


   sets the active element to be that of the provider selector on
   transmitted packets.


5.3.  Extended Address (Address Sequence)

   Now assume that at some point 64 bits become inadequate and addresses
   are extended to an address sequence of two 64-bit addresses.  In this
   case, H's address sequences are P.D:S.H and Q.D:S.H, where the colon
   ':' indicates a 64-bit boundary, and S represents a subnet inside
   domain D.  I's address sequences are Q.E:S.I and R.E:S.I.

   For H to send a packet to I, it could form:

        Route sequence at sender H: S.H, Q.D, *Q.E, S.I

   The active element Q.E would cause the packet to be routed to domain
   E, where the Routing Header would be advanced to:

        Advanced route sequence at router in Domain E: S.H, Q.D, Q.E,
        *S.I

   and delivered to I.

   The above reversing rules executed by I would produce:

        Reversed route sequence at receiver I: S.I, Q.E, *Q.D, S.H

   thus returning the packet to I.

6.  MULTICASTING IN SIPP

   This section describes how traditional multicast [5] works using SIPP
   route sequences.  As with unicast, SIPP multicast address sequences
   are described using a series of 64-bit address elements.  Thus, the
   node's notion of multicast addressing is extended such that a "multi-
   cast address" is seen as an address sequence rather than a single
   multicast address as is the case with IP.  The final element of the
   multicast address sequence is the group ID.

   When a node joins a multicast group, it considers the multicast
   address sequence to be one of its own address sequences for the sake
   of packet reception and reversal.  The multicast address sequence is
   not source-capable.

   In traditional multicast (also known as Deering multicast or source-
   based multicast), a packet from a sender to a multicast group is sent
   on the shortest-path delivery tree (rooted at the sender) to members



SIP WG, Expires April 1, 1994                                 [Page 12]


                    draft-ietf-sip-overview-00.txt         October 1993


   of the group.  The traditional SIPP multicast address sequence con-
   tains only one address--the group ID.  This section describes the
   Routing Header that is formed by the sender, the reversed Routing
   Header formed by the receiver and the necessary extensions to the
   multicast forwarding algorithm.

6.0.1.  Example

   Assume the same scenario as described above (with nodes H and I),
   further assuming that H and I have extended addresses as described
   above.  (We do an extended address example here because the simple
   address example is the same as with current IP.) Assume further that
   H is transmitting a traditional multicast with multicast address M,
   and that I is a member of group M.  H forms the following header:

        Route sequence at sender H: S.H, Q.D, *M

   The route sequence is received unchanged at each of the receivers.

   If I wishes to respond unicast to H, it executes the reversing rules
   described above in the following way.  First, it isolates its own
   address from the route sequence.  Since this is multicast, and since
   I is a member of the multicast group M, I considers M to be one of
   its "own" addresses, and strips it.  Reversing what remains produces
   <Q.D, P.H>.  Since a multicast address cannot be used as a source
   address, I knows to prepend its own unicast address sequence to the
   route sequence, producing:

        Reversed route sequence at receiver I: S.I, Q.E, *Q.D, S.H


6.0.2.  Multicast Forwarding Extensions

   With traditional multicast, each router's next hops are dependent
   both on the multicast group address and the sender address.  When the
   sender's address is an address sequence next hop determination is
   potentially influenced by all of the addresses in the sequence.

   In the header formed by the sender, the SIPP Routing Header part con-
   tains all but the low-order address.  Therefore, each multicast
   router will need to parse SIPP options for every packet containing a
   multicast destination address.  For instance, in the above example,
   the routers would need to look at the destination address to deter-
   mine that it is multicast, then look in the Routing Header at "Q.D",
   then if necessary (for instance, because the packet is still inside
   domain D) look at "S.H" in the source address field.

   While this represents additional overhead, routers will not need to



SIP WG, Expires April 1, 1994                                 [Page 13]


                    draft-ietf-sip-overview-00.txt         October 1993


   incur this "peek-behind" overhead until 64-bit addresses are insuffi-
   cient for global routability of Internet nodes.

7.  MOBILITY IN SIPP

   This section shows how SIPP source routing and SIPP route sequences
   might be used for mobile communication.  Note that the Mobile IP
   group of IETF is deliberating on various solutions for mobility, and
   may choose a different approach than the one outlined here.  At the
   same time, more approaches are possible with SIPP than with IP, so
   the Mobile IP group may choose a different solution for use with
   SIPP.  First, we introduce some terminology.

   Mobile Host (MH)
      A node that is able to maintain its network connections even after
      being physically moved.

   Correspondent Host (CH)
      A node that has a network connection open to an MH. A CH may
      itself be mobile.

   Base Station (BS)
      The SIPP router to which the MH is attached after it moves.

   Home Station (HS)
      A SIPP node that is aware of the MH's current location. Each MH
      has a preconfigured home station.


7.1.  Mobility Example

   Assume that H is an MH and that I is the CH, both with the (extended)
   address sequences from above.  Initially, a packet from the CH to the
   MH carries the following route sequence as in the above example:

        Route sequence from CH to MH: S.I, Q.E, *Q.D, S.H

   Now suppose the MH moves to the vicinity of a BS with an address D.d.
   MH discovers D.d through SIPP "I-Am-Here" advertisements.  These are
   multicast by the BS to the SIPP All Nodes address (similar to an IS
   hello advertisement in ES-IS).  MHs also periodically multicast SIPP
   "I-Am-Here" advertisements to the SIPP All Routers multicast address
   (similar to the ES hello advertisement in ES-IS).  This latter adver-
   tisement contains the MH's identifying address.

   Through a mechanism beyond the scope of this document, the MH informs
   the HS of its new base station.  Packets carrying the old route
   sequence from the CH are intercepted by the HS.  The HS tunnels them



SIP WG, Expires April 1, 1994                                 [Page 14]


                    draft-ietf-sip-overview-00.txt         October 1993


   to the BS, which forwards it to the MH.

   After the MH has discovered D.d, all subsequent packets to the CH
   carry the following route sequence:

        Route sequence from MH to CH after move: S.H, D.d, *Q.E, S.I

   It is sufficient to include only MH's identifying address in the
   route sequence; we assume that the BS is within I's IADs (S.I) rout-
   ing scope.  When the CH reverses the incoming route sequence from the
   MH, it created the following route sequence:

        Reversed route sequence from CH to MH after move: S.I, Q.E,
        *D.d, S.H

   This causes packet to the MH to be routed through the BS at D.d, pro-
   ducing the desired behavior.

8.  HOST AUTO-CONFIGURATION

   This section describes how a host constructs a temporary IAD when it
   boots and uses that to contact DNS or some configuration server to
   obtain host configuration information.  We are interested in the four
   scenarios comprised of the combinations whereby 1) either a router is
   or is not on the host's local link, and 2) either the host can or
   cannot contact a configuration server.

   When a host boots up, it assigns itself a temporary local-use IAD
   formed from its link address.  This IAD is routable only within the
   link on which the host is located.

   The host then sends out a small number of SIPP "Where-Are-You" soli-
   citations with the local-use IAD as the source address.  If it
   receives no advertisements, the host assumes that there is no router
   on the link and uses the temporary IAD to communicate with other
   nodes on the link.  If, using this IAD, the host is able to contact a
   configuration server on the link, then it may obtain a different,
   possibly global, address at this time.

   Once it hears a router advertisement, a host can use one of the
   advertised prefixes to form an address with greater routing scope.
   This address can be used to contact the configuration server.  (The
   address of the configuration server could be a well-known multicast
   address.) If any of the prefixes advertised by the router is small
   enough to accommodate the host's link address (e.g., in the case of a
   multi-link domain not connected to the Internet), the host can con-
   catenate that prefix with its link address to form its address.  Oth-
   erwise, the host can assign itself the address sequence <C, T>, where



SIP WG, Expires April 1, 1994                                 [Page 15]


                    draft-ietf-sip-overview-00.txt         October 1993


   T is the host's local-use IAD, and C is the cluster address of the
   subnet learned from the router advertisement.

   If a configuration server responds with a new address, the host uses
   that address.  Otherwise, the host continues to use the previous
   address to communicate with other nodes (either in its domain or glo-
   bally).  Note that the design of a configuration server is an open
   issue.



References


[1]  S. Deering, "Simple Internet Protocol (SIP) Specification", Inter-
     net Draft, work in progress.

[2]  P. Francis, "Pip Near-term Architecture", Internet Draft, work in
     progress.

[3]  V. Fuller, T. Li, K. Varadhan, J. Yu, "Supernetting: an Address
     Assignment and Aggregation Strategy", RFC 1338.

[4]  P. Tsuchiya, "On the Assignment of Subnet Numbers", RFC 1219.

[5]  S. Deering, "Host Extensions for IP multicasting", RFC 1112.

[6]  R. Gilligan et al, "SIPP Transition Mechinisms", Internet Draft,
     work in progress.

[7]  P. Francis, "On the Assignment of Provider Rooted Addresses",
     Internet Draft, work in progress.

[8]  S. Deering, "Simple Internet Protocol Plus (SIPP) Specification",
     Internet Draft, work in progress.

[9]  R. Colellea, E. Gardner, R. Callon, "Guidelines for OSI NSAP Allo-
     cation in the Internet", RFC1237.













SIP WG, Expires April 1, 1994                                 [Page 16]


                    draft-ietf-sip-overview-00.txt         October 1993


APPENDIX A: PROPOSED UNICAST GLOBAL SIPP ADDRESS ASSIGNMENT

   This appendix proposes an initial assignment scheme for SIPP global
   hierarchical unicast addresses that has the following characteris-
   tics:

   1.   it accommodates existing IP addresses,

   2.   it is an extension of the CIDR address assignment scheme,

   3.   it leaves address space open for several avenues of future
        growth.

   The initial assignment scheme for SIPP unicast addresses is
   provider-based, as follows:


     |1|      n bits       |        m bits       |   p bits  | 63-n-m-p|
     +-+-------------------+---------------------+-----------+---------+
     |C|    provider ID    |    subscriber ID    | subnet ID | node ID |
     +-+-------------------+---------------------+-----------+---------+
                           |                                           |
                           |     corresponds to current IP address     |

C-bit

   The left-most bit is the IPv4 compatibility flag [6], known as the
   C-bit.  Both SIPP and IPv4 hosts can be assigned SIPP addresses in
   the SIPP unicast address space.  Even though IPv4 hosts may be listed
   in the DNS with 64-bit SIPP addresses, they only "know" the low-order
   32-bit part of their address.  The C-bit is used by SIPP nodes to
   differentiate SIPP systems from IPv4 systems.  SIPP systems are
   always assigned addresses with the C-bit set to 0.  IPv4 systems are
   always given addresses with the C-bit set to 1.


Provider Assignments

   Initially, the provider ID will be 31 bits in length.  The provider
   mask is 32 bits in length (covering the provider ID and the C-bit).
   Provider IDs initially have the following format:

     | 8 bits |     24 bits           |
     +--------+-----------------------+
     |C0000000| provider ID, assigned |
     |        | "from the left" [4]   |
     +--------+-----------------------+




SIP WG, Expires April 1, 1994                                 [Page 17]


                    draft-ietf-sip-overview-00.txt         October 1993


   The leftmost 7 bits of the provider ID (not including the C-bit) are
   assigned as 0.  The subsequent 24 bits are assigned values according
   to the technique of assigning IP subnet numbers outlined in RFC 1219
   [4].  That is, the "1" bits of the values are filled in from left-
   to-right rather than from right-to-left.  This style of assignment
   reserves 0's on the right side of the provider ID, thus allowing the
   mask of a given provider to shrink in the future, if it is found that
   the provider needs more bits, for instance to identify its sub-
   scribers.

   For example, initial provider ID assignment would proceed as follows:
         first provider:  C0000000 10000000 00000000 00000000
        second provider:  C0000000 01000000 00000000 00000000
         third provider:  C0000000 11000000 00000000 00000000
        fourth provider:  C0000000 00100000 00000000 00000000
         fifth provider:  C0000000 10100000 00000000 00000000
                          ....
         tenth provider:  C0000000 01010000 00000000 00000000

   This initial assignment of the provider ID space (zeros to both the
   left and right of the assigned bits) allows for several avenues of
   growth.

   For instance, if internet growth results in a small number of very
   large providers, then the masks of the providers can be shrunk, thus
   giving each provider more space, which could be used to add another
   level of hierarchy within the provider.  If providers grew so large
   that they required even more space, they could be allocated codes in
   the most significant byte of the provider ID space.

   The reserved space in the most significant byte could also be used
   for different kinds of number assignments, such as geographical or
   organizational, if that becomes desirable in the future.  (Strictly
   speaking it wouldn't be necessary for such different number assign-
   ments to have their own contiguous number spaces.  For instance, the
   geographical codes could come from a portion of the provider space.
   However, having separate contiguous number spaces for different types
   of addresses simplifies address administration within each space.)

   If internet growth results in a large number of small providers, then
   it might be necessary for the zero bits in the most significant byte
   to be used as an additional layer of hierarchy above the provider
   level.


Assignment of Lower 32 Bits

   The lower 32-bits of the SIPP address is initially nothing more than



SIP WG, Expires April 1, 1994                                 [Page 18]


                    draft-ietf-sip-overview-00.txt         October 1993


   the current IP address.  After the IP address space expires (is no
   longer globally unique), then the lower 32 bits of the SIPP address
   will no longer by itself be globally unique, and will be assigned by
   the addressing authority identified by the higher 32 bits of the SIPP
   address (rather than being assigned by the current IP top-level
   address assignment authority).

   IP addresses currently exist under two formats, class-based (pre-
   CIDR) and class-less (CIDR) [3].  Pre-CIDR assignments have the fol-
   lowing format:

     |    m bits    | p bits  | 32-m-p |
     +--------------+---------+--------+
     |   network    | subnet  |  host  |
     +--------------+---------+--------+

   The IP network number corresponds to the SIPP subscriber ID.  The
   SIPP subnet ID and node ID correspond to the IP subnet and host
   numbers respectively.  The network number is globally unique among
   network numbers.  Thus, providers have no control over the assignment
   of subscriber IDs derived from pre-CIDR IP addresses.

   CIDR assignments have the following format:

     |  n bits     |    m bits    | p bits  |32-n-m-p|
     +-------------+--------------+---------+--------+
     | provider ID |subscriber ID | subnet  |  host  |
     +-------------+--------------+---------+--------+

   Under CIDR, providers have control of subscriber assignments.  After
   IP addresses are no longer unique, providers will also have control
   over the top n bits of the "IP address" (the lower 32 bits).  These
   bits can be used either to assign directly to more subscribers, or to
   create a level of hierarchy above the subscriber level, resulting in:

     |1|   31 bits   |    n bits      |    m bits    | p bits  |32-n-m-p|
     +-+-------------+----------------+--------------+---------+--------+
     |C| provider ID |sub-provider ID |subscriber ID |subnet ID|node ID |
     +-+-------------+----------------+--------------+---------+--------+

   As mentioned above, it will also be possible for the sub-provider ID
   to grow into the provider ID space, by shrinking the provider mask
   for the provider.  In general, as the internet grows, the structure
   of the SIPP global address may evolve to accommodate the growth.  In
   the extreme case, the SIPP global address can expand to greater than
   64 bits.

   Note that the use of provider-based addresses results in multiple



SIP WG, Expires April 1, 1994                                 [Page 19]


                    draft-ietf-sip-overview-00.txt         October 1993


   address prefixes for subscriber domains that are attached to multiple
   providers [7].  While this has the advantage of giving nodes a pro-
   vider selection feature, it has the disadvantage of added complexity
   in nodes, DNS, and address administration.















































SIP WG, Expires April 1, 1994                                 [Page 20]