RFC relevance of requirement

As per Relevance of the word requirement, we have this rfc below:

Network Working Group N.
Request for Comments: 1753 December 1994
Category:

IPng Technical
Of the Nimrod Routing and Addressing

Status of this

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list

This document presents the requirements that the Nimrod routing
addressing architecture has upon the internetwork layer protocol.
be most useful to Nimrod, any protocol selected as the IPng
satisfy these requirements. Also presented is some
information, consisting of i) information about architectural
design principles which might apply to the design of a
internetworking layer, and ii) some details of the logic
reasoning behind particular requirements

1.

It is important to note that this document is not "IPng
for Routing", as other proposed routing and addressing designs
need different support; this document is specific to Nimrod,
doesn't claim to speak for other efforts

However, although I don't wish to assume that the particular
being worked on by the Nimrod WG will be widely adopted by
Internet (if for no other reason, they have not yet been deployed
tried and tested in practise, to see if they really work,
absolutely necessary hurdle for any protocol), there are reasons
believe that any routing architecture for a large, ubiquitous
Internet will have many of the same basic fundamental principles
the Nimrod architecture, and the requirements that these generate

Chiappa [Page 1]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

While current day routing technologies do not yet have
characteristics and capabilities that generate these requirements
they also do not seem to be completely suited to routing in
next-generation Internet. As routing technology moves towards what
needed for the next generation Internet, the underlying
laws and principles of routing will almost inevitably drive
design, and hence the requirements, toward things which look like
material presented here

Therefore, even if Nimrod is not the routing architecture of
next-generation Internet, the basic routing architecture of
Internet will have requirements that, while differing in detail,
almost inevitably be similar to these

In a similar, but more general, context, note that, by and large,
general analysis of sections 3.1 ("Interaction Architectural Issues")
and 3.2 ("State and Flows in the Internetwork Layer") will apply
other areas of a new internetwork layer, not just routing

I will tackle the internetwork packet format first (which
simpler), and then the whole issue of the interaction with the
of the internetwork layer (which is a much more subtle topic).

2. Packet

2.1 Packet Format

As a general rule, the design philosophy of Nimrod is "maximize
lifetime (and flexibility) of the architecture". Design
(i.e., optimizations) that will adversely affect the flexibility
adaptability and lifetime of the design are not not necessarily
choices; they may cost more than they save. Such optimizations
be the correct choices in a stand-alone system, where the
costs are relatively small; in the global communication network,
replacement costs are very much higher

Providing the Nimrod functionality requires the carrying of
information in the packets. The design principle noted above has
number of corollaries in specifying the fields to contain
information

First, the design should be "simple and straightforward", which
that various functions should be handled by completely
mechanisms, and fields in the packets. It may seem that
opportunity exists to save space by overloading two functions
one mechanism or field, but general experience is that, over time
this attempt at optimization costs more, by restricting
and adaptability

Chiappa [Page 2]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

Second, field lengths should be specified to be somewhat larger
can conceivably be used; the history of system architecture
replete with examples (processor address size being the
notorious) where fields became too short over the lifetime of
system. The document indicates what the smallest
"adequate" lengths are, but this is more of a "critical floor" than
recommendation. A "recommended" length is also given, which is
length which corresponds to the application of this principle.
wise designer would pick this length

It is important to now that this does *not* mean that
must support the maximum value possible in a field of that size.
imagine that system-wide administrative limits will be placed on
maximum values which must be supported. Then, as the need arises,
can increase the administrative limit. This allows an easy,
completely interoperable (with no special mechanisms) path to
the capability of the network. If the maximum supported value of
field needs to be increased from M to N, an announcement is made
this is coming; during the interim period, the system continues
operate with M, but new implementations are deployed; while this
happening, interoperation is automatic, with no transition
of any kind needed. When things are "ready" (i.e., the proportion
old equipment is small enough), use of the larger value commences

Also, in speaking of the packet format, you first need to
between the host-router part of the path, and the router-router part
a format that works OK for one may not do for another

The issue is complicated by the fact that Nimrod can be made to work
albeit not in optimal form, with information/fields missing from
packet in the host to "first hop router" section of the packet'
path. The missing fields and information can then be added by
first hop router. (This capability will be used to allow
and operation with unmodified IPv4 hosts, although similar
could be used with other internetworking protocols.) Access to
full range of Nimrod capabilities will require upgrading of hosts
include the necessary information in the packets they exchange
the routers

Second, Nimrod currently has three planned forwarding modes (flows
datagram, and source-routed packets), and a format that works for
may not work for another; some modes use fields that are not used
other modes. The presence or absence of these fields will make
difference

Chiappa [Page 3]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

2.2 Packet Format

What Nimrod would like to see in the internetworking packet is

- Source and destination endpoint identification. There are
possibilities here

One is "UID"s, which are "shortish", fixed length fields
appear in each packet, in the internetwork header, which
globally unique, topologically insensitive identifiers for
i) endpoints (if you aren't familiar with endpoints, think of
as hosts), or ii) multicast groups. (In the former instance,
UID is an EID; in the latter, a "set ID", or SID. An SID is
identifier which looks just like an EID, but it refers to a
of endpoints. The semantics of SID's are not completely defined.)
For each of these 48 bits is adequate, but we would recommend 64
bits. (IPv4 will be able to operate with smaller ones for a while
but eventually either need a new packet format, or the
and not wholly satisfactory technique known as Network
Translators, which allows the contents of these fields to be
locally unique.)

Another possibility is some shorter field, named an "
selector", or ESEL, which contains a value which is not
unique, but only unique in mapping tables on each end, tables
map from the small value to a globally unique value, such as a
name

Finally, it is possible to conceive of overall networking
which do not include any endpoint identification in the packet
all, but transfer it at the start of a communication, and from
on infer it. This alternative would have to have some other
of telling which endpoint a given packet is for, if there
several endpoints at a given destination. Some coordination
allocation of flow-ids, or higher level port numbers, etc.,
do this

- Flow identification. There are two basic approaches here,
on whether flows are aggregated (in intermediate switches) or not
It should be emphasized at this point that it is not yet
whether flow aggregation will be needed. The only reason to do
is to control the growth of state in intermediate routers,
there is no hard case made that either this growth will
unmanageable, or that aggregating flows will be
practically

Chiappa [Page 4]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

For the non-aggregated case, a single "flow-id" field will suffice
This *must not* use one of the two previous UID fields, as
datagram mode (and probably source-routed mode as well) the flow-
will be over-written during transit of the network. It could
easily be constructed by adding a UID to a locally unique flow-id
which will provide a globally unique flow-id. It is possible to
non-globally unique flow-ids, (which would allow a shorter
to this field), although this would mean that collisions
result, and have to be dealt with. An adequate length for the
part of a globally unique flow-id would be 12 bits (which would
my "out of thin air" guess), but we recommend 32. For a non
globally unique flow-id, 24 bits would be adequate, but I
32.

For the aggregated case, three broad classes of mechanism
possible

- Option 1: The packet contains a sequence (sort of like a
route) of flow-ids. Whenever you aggregate or deaggregate,
move along the list to the next one. This takes the most space
but is otherwise the least work for the routers

- Option 2: The packet contains a stack of flow-ids, with
current one on the top. When you aggregate, you push a new
on; when you de-aggregate, you take one off. This takes
work, but less space in the packet than the complete "source
route". Encapsulating packets to do aggregation does
this, but you're stacking entire headers, not just flow-ids.
clever way to do this flow-id stacking, without
encapsulation, is to find out from flow-setup how deep the
will get, and allocate the space in the packet when it'
created. That way, all you ever have to do is insert a
flow-id, or "remove" one; you never have to make room for
flow-ids

- Option 3: The packet contains only the "base" flow-id (i.e.,
one with the finest granularity), and the current flow-id.
you aggregate, you just bash the current flow-id. The
part comes when you de-aggregate; you have to put the
value back. To do this, you have to have state in the router
the end of the aggregated flow, which tells you what the de
aggregated flow for each base flow is. The downside here
obvious: we get away without individual flow state for each
the constituent flows in all the routers along the path of
aggregated, flow, *except* for the last one

Chiappa [Page 5]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

Other than encapsulation, which has significant inefficiency
space overhead fairly quickly, after just a few layers
aggregation, there appears to be no way to do it with just
flow-id in the packet header. Even if you don't touch
packets, but do the aggregation by mapping some number of "base
flow-id's to a single aggregated flow in the routers along
path of the aggregated flow, the table that does the mapping
still going to have to have a number of entries
proportional to the number of base flows going through
switch

- A looping packet detector. This is any mechanism that will detect
packet which is "stuck" in the network; a timeout value in packets
together with a check in routers, is an example. If this is a hop
count, it has to be more than 8 bits; 12 bits would be adequate
and I recommend 16 (which also makes it easy to update). This
not to say that I think networks with diameters larger than 256
good, or that we should design such nets, but I think limiting
maximum path through the network to 256 hops is likely to bite
down the road the same way making "infinity" 16 in RIP did (as
did, eventually). When we hit that ceiling, it's going to hurt,
there won't be an easy fix. I will note in passing that we
already seeing paths lengths of over 30 hops

- Optional source and destination locators. These are structured
variable length items which are topologically sensitive
for the place in the network from which the traffic originates
to which the traffic is destined. The locator will probably
internal separators which divide up the fields, so that
particular field can be enlarged without creating a great deal
upheaval. An adequate value for maximum length supported would
up to 32 bytes per locator, and longer would be even better;
would recommend up to 256 bytes per locator

- Perhaps (paired with the above), an optional pointer into
locators. This is optional "forwarding state" (i.e., state in
packet which records something about its progress across
network) which is used in the datagram forwarding mode to
ensure that the packet does not loop. It can also improve
forwarding processing efficiency. It is thus not
essential, but is very desirable from a real-world engineering
point. It needs to be large enough to identify locations in
locator; e.g., if locators can be up to 256 bytes, it would need
be 9 bits

- An optional source route. This is used to support the "
routed packet" forwarding mode. Although not designed in
yet, we can discuss two possible approaches

Chiappa [Page 6]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

In one, used with "semi-strict" source routing (in which
contiguous series of entities is named, albeit perhaps at a
layer of abstraction), the syntax will likely look much like
routes in PIP; in Nimrod they will be a sequence of Nimrod
identifiers (i.e., locator elements, not complete locators),
with clues as to the context in which each identifier is to
interpreted (e.g., up, down, across, etc.). Since those
themselves are variable length (although probably most will be
bytes or less, otherwise the routing overhead inside the
object would be excessive), and the hop count above
the possibility of paths of over 256 hops, it would seem that
might possibly some day exceed 512 bytes, if a lengthy path
specified in terms of the actual physical assets used. An
length would be 512 bytes; the recommended length would be 2^16
bytes (although this length would probably not be supported
practise; rather, the field length would allow it).

In the other, used with classical "loose" source routes, the
consists of a number of locators. It is not yet clear if this
will be supported. If so, the header would need to be able to
a sequence of locators (as described above). Space might be
by not repeating locator prefixes that match that of the
locator in the sequence; Nimrod will probably allow use of
"locally useful" locators. It is hard to determine what an
length would be for this case; the recommended length would be 2^16
bytes (again, with the previous caveat).

- Perhaps (paired with the above), an optional pointer into
source route. This is also optional "forwarding state". It needs
be large enough to identify locations anywhere in the source route
e.g., if the source router can be up to 1024 bytes, it would
to be 10 bits

- An internetwork header length. I mention this since the
fields could easily exceed 256 bytes, if they are to all be
in the internetwork header (see comments below as to where to
all this information), the header length field needs to be
than 8 bits; 12 bits would be adequate, and I recommend 16 bits
The approach of putting some of the data items above into
interior header, to limit the size of the basic
header, does not really seem optimal, as this data is for use
the intermediate routers, and it needs to be easily accessible

- Authentication of some sort is needed. See the recent IAB
which was produced as a result of the IAB architecture retreat
security (draft-iab-sec-arch-workshop-00.txt), section 4,
especially section 4.3. There is currently no set way of
"denial/theft of service" in Nimrod, but this topic is

Chiappa [Page 7]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

explored in that document; Nimrod would use whatever mechanism(s
seem appropriate to those knowledgeable in this area

- A version number. Future forwarding mechanisms might need
information (i.e., fields) in the packet header; use a
number would allow it to be modified to contain what's needed
(This would not necessarily be information that is visible to
hosts, so this does not necessarily mean that the hosts would
to know about this new format.) 4 bits is adequate; it's not
if a larger value needs to be recommended

2.3 Field Requirements and Addition

As noted above, it's possible to use Nimrod in a limited mode
needed information/fields are added by the first-hop router. It'
thus useful to ask "which of the fields must be present in the host
router header, and which could be added by the router?" The only
which are absolutely necessary in all packets are the
identification (provided that some means is available to map
into locators; this would obviously be most useful on UID's which
EID's).

As to the others, if the user wishes to use flows, and wants
guarantee that their packets are assigned to the correct flows,
flow-id field is needed. If the user wishes efficient use of
datagram mode, it's probably necessary to include the locators in
packet sent to the router. If the user wishes to specify the
for the packets, and does not wish to set up a flow, they need
include the source route

How would additional information/fields be added to the packet,
the packet is emitted from the host in incomplete form? (By this,
mean the simple question of how, mechanically, not the more
issue of where any needed information comes from.)

This question is complex, since all the IPng candidates (and in fact
any reasonable inter-networking protocol) are extensible protocols
those extension mechanisms could be used. Also, it would possible
carry some of the required information as user data in
internetworking packet, with the original user's data
further inside. Finally, a private inter-router packet format
be defined

It's not clear which path is best, but we can talk about which
the Nimrod routers need access to, and how often; less used
could be placed in harder-to-get-to locations (such as in
encapsulated header). The fields to which the routers need access
every hop are the flow-id and the looping packet detector.

Chiappa [Page 8]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

locator/pointer fields are only needed at intervals (in what
forwarding mode calls "active" routers), as is the source route (
latter at every object which is named in the source route).

Depending on how access control is done, and which forwarding mode
used, the UID's and/or locators might be examined for access
purposes, wherever that function is performed

This is not a complete exploration of the topic, but should give
rough idea of what's going on

3. Architectural

3.1 Interaction Architectural

The topic of the interaction with the rest of the internetwork
is more complex. Nimrod springs in part from a design vision
sees the entire internetwork layer, distributed across all the
and routers of the internetwork, as a single system, albeit
distributed system

Approached from that angle, one naturally falls into a typical
designer point of view, where you start to think of
modularization of the system; chosing the functional boundaries
divide the system up into functional units, and defining
interactions between the functional units. As we all know,
modularization is the key part of the system design process

It's rare that a group of completely independent modules form
system; there's usually a fairly strong internal interaction.
interactions have to be thought about and understood as part of
modularization process, since it effects the placement of
functional boundaries. Poor placement leads to complex interactions
or desired interactions which cannot be realized

These are all more important issues with a system which is
to have a long lifetime; correct placement of the
boundaries, so as to clearly and simply break up the system
truly fundamental units, is a necessity is the system is to
and serve well

3.1.1 The Internetwork Layer Service

To return to the view of the internetwork layer as a system,
system provides certain services to its clients; i.e.,
instantiates a service model. To begin with, lacking a shared view
the service model that the internetwork layer is supposed to provide
it's reasonable to suppose that it will prove impossible to agree

Chiappa [Page 9]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

mechanisms at the internetwork level to provide that service

To answer the question of what the service model ought to be, one
view the internetwork layer itself as a subsystem of an even
system, the entire internetwork itself. (That system is quite
the largest and most complex system we will ever build, as it is
largest system we can possibly build; it is the system which
inevitably contain almost all other systems.)

From that point of view, the issue of the service model of
internetwork layer becomes a little clearer. The services provided
the internetwork layer are no longer purely abstract, but can
thought about as the external module interface of the
layer module. If agreement can be reached on where to put
functional boundaries of the internetwork layer, and on what
service the internet as a whole should provide, the service model
the internetwork layer should be easier to agree on

In general terms, it seems that the unreliable packet ought to
the fundamental building block of the internetwork layer. The
principle that says that we can take any packet and throw it
with no warning or other action, or take any router and turn it
with no warning, and have the system still work, seems very powerful
The component design simplicity (since routers don't have to stand
their heads to retain a packet which they have the only copy of),
overall system robustness, resulting from these two assumptions
absolutely critical

In detail, however, particularly in areas which are still the
of research and experimentation (such as resource allocation
security, etc.), it seems difficult to provide a finished
of exactly what the service model of the internetwork layer ought
be

3.1.2 The Subsystems of the Internetwork

In any event, by viewing the internetwork layer as a large system
one starts to think about what subsystems are needed, and what
interactions among them should look like. Nimrod is simply a
of the subsystems of this larger system, the internetwork layer.
is *not* intended to be a purely standalone set of subsystems, but
work together in close concert with the other subsystems of
internetwork layer (resource allocation, security, charging, etc.)
provide the internetwork layer service model

One reason that Nimrod is not simply a monolithic subsystem is
some of the interactions with the other subsystems of
internetwork layer, for instance the resource allocation subsystem

Chiappa [Page 10]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

are much clearer and easier to manage if the routing is broken
into several subsystems, with the interactions between them open

It is important to realize that Nimrod was initially broken up
separate subsystems for purely internal reasons. It so happens that
considered as a separate problem, the fundamental boundary lines
dividing routing up into subsystems are the same boundaries that
interaction with other subsystems cleaner; this provides
evidence that these boundaries are in fact the right ones

The subsystems which comprise the functionality covered by Nimrod
i) routing information distribution (in the case of Nimrod,
map distribution, along with the attributes [policy, QOS, etc.]
the topology elements), ii) route selection (strictly speaking,
part of the Nimrod spec per se, but functional examples will
produced), and iii) user traffic handling

The former can fairly well be defined without reference to
subsystems, but the second and third are necessarily more involved
For instance, route selection might involve finding out which
have the resources available to handle some required level
service. For user traffic handling, if a particular application
a resource reservation, getting that resource reservation to
routers is as much a part of getting the routers ready as making
they have the correct routing information, so here too, routing
tied in with other subsystems

In any event, although we can talk about the relationship between
Nimrod subsystems, and the other functional subsystems of
internetwork layer, until the service model of the internetwork
is more clearly visible, along with the functional boundaries
that layer, such a discussion is necessarily rather nebulous

3.2 State and Flows in the Internetwork

The internetwork layer as whole contains a variety of information,
varying lifetimes. This information we can refer to as
internetwork layer's "state". Some of this state is stored in
routers, and some is stored in the packets

In the packet, I distinguish between what I call "forwarding state",
which records something about the progress of this individual
through the network (such as the hop count, or the pointer into
source route), and other state, which is information about
service the user wants from the network (such as the destination
the packet), etc

Chiappa [Page 11]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

3.2.1 User and Service

I call state which reflects the desires and service requests of
user "user state". This is information which could be sent in
packet, or which can be stored in the router and applied to
packets (depending on which makes the most engineering sense). It
still called user state, even when a copy is stored in the routers

User state can be divided into two classes; "critical" (such
destination addresses), without which the packets cannot be
at all, and "non-critical" (such as a resource allocation class),
without which the packets can still be forwarded, just not quite
the way the user would most prefer

There are a range of possible mechanisms for getting this user
to the routers; it may be put in every packet, or placed there by
setup. In the latter case, you have a whole range of
for how to get it back when you lose it, such as placing a copy
every Nth packet

However, other state is needed which cannot be stored in each packet
it's state about the longer-term (i.e., across the life of
packets) situation; i.e., state which is inherently associated with
number of packets over some time-frame (e.g., a resource allocation).
I call this state "server state".

This apparently changes the "stateless" model of routers somewhat
but this change is more apparent than real. The routers
contain state, such as routing table entries; state without which
it virtually impossible to handle user traffic. All that is
changed is the amount, granularity, and lifetime, of state in
routers

Some of this service state may need to be installed in a
reliable fashion; e.g., if there is service state related to billing
or allocation of resources for a critical application, one more
less needs to be guaranteed that this service state has
correctly installed

To the extent that you have state in the routers (either
state, or user state), you have to be able to associate that
with the packets it goes with. The fields in the packets that
you to do this are "tags".

Chiappa [Page 12]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

3.2.2

It is useful to step back for a bit here, and think about the
in the network. Some of it will be from applications with
basically transactions; i.e., they require only a single packet, or
very small number. (I tend to use the term "datagram" to refer
such applications, and use the term "packet" to describe the unit
transmission through the network.) However, other packets are part
longer-lived communications, which have been termed "flows".

A flow, from the user's point of view, is a sequence of packets
are associated, usually by being from a single application instance
In an internetwork layer which has a more complex service
(e.g., supports resource allocation, etc.), the flow would
service requirements to pass on to some or all of the
which provide those services

To the internetworking layer, a flow is a sequence of packets
share all the attributes that the internetworking layer cares about
This includes, but is not limited to: source/destination, path
resource allocation, accounting/authorization
authentication/security, etc., etc

There isn't necessarily a one-one mapping from flows to *anything
else, be it a TCP connection, or an application instance,
whatever. A single flow might contain several TCP connections (e.g.,
with FTP, where you have the control connection, and a number of
connections), or a single application might have several flows (e.g.,
multi-media conferencing, where you'd have one flow for the audio
another for a graphic window, etc., with different
requirements in terms of bandwidth, delay, etc., for each.)

Flows may also be multicast constructs, i.e., multiple sources
destinations; they are not inherently unicast. Multicast flows
more complex than unicast (there is a large pool of state which
be made coherent), but the concepts are similar

There's an interesting architectural issue here. Let's assume we
all these different internetwork level subsystems (routing,
allocation, security/access-control, accounting), etc. Now, we
two choices

First, we could allow each individual subsystem which uses
concept of flows to define itself what it thinks a "flow" is,
define which values in which fields in the packet define a
"flow" for it. Now, presumably, we have to allow 2 flows
subsystem X to map onto 1 flow for subsystem Y to map onto 3
for subsystem Z; i.e., you can mix and match to your heart's content

Chiappa [Page 13]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

Second, we could define a standard "flow" mechanism for
internetwork layer, along with a way of identifying the flow in
packet, etc. Then, if you have two things which wish to differ
*any* subsystem, you have to have a separate flow for each

The former has the advantages that it's a little easier to
incrementally, since you don't have to agree on a common
mechanism. It may save on replicated state (if I have 3 flows,
they are the same for subsystem X, and different for Y, I only
one set of X state). It also has a lot more flexibility. The
is simple and straightforward, and given the complexity of what
being proposed, it seems that any place we can make things simpler
we should

The choice is not trivial; it all depends on things like "
percentage of flows will want to share the same state in
subsystems with other flows". I don't know how to quantify those,
as an architect, I prefer simple, straightforward things. This
is pretty complex already, and I'm not sure the benefits of
able to mix and match are worth the added complexity. So, for
moment I'll assume a single, system-wide, definition of flows

The packets which belong to a flow could be identified by a
consisting of a number of fields (such as addresses, ports, etc.),
opposed to a specialized field. However, it may be
straightforward, and foolproof, to simply identify the flow a
belongs to with by means of a specialized tag field (the "flow-id" )
in the internetwork header. Given that you can always find
where the existing fields alone don't do the job, and you *still
need a separate field to do the job correctly, it seems best to
the simple, direct approach , and say "the flow a packet belongs
is named by a flow-id in the packet header".

The simplicity of globally-unique flow-id's (or at least a flow-
which unique along the path of the flow) is also desirable; they
more bits in the header, but then you don't have to worry about
the mechanism needed to remap locally-unique flow-id's, etc., etc
From the perspective of designing something with a long lifetime,
which is to be deployed widely, simplicity and directness is the
way to go. For me, that translates into flows being named solely
globally unique flow-id's, rather than some complex semantics
existing fields

However, the issue of how to recognize which packets belong to
is somewhat orthogonal to the issue of whether the internetwork
recognizes flows at all. Should it

Chiappa [Page 14]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

3.2.3 Flows and

To the extent that you have service state in the routers you have
be able to associate that state with the packets it goes with.
is a fundamental reason for flows. Access to service state is
reason to explicitly recognize flows at the internetwork layer,
it is not the only one

If the user has requirements in a number of areas (e.g., routing
access control), they can theoretically communicate these to
routers by placing a copy of all the relevant information in
packet (in the internetwork header). If many subsystems of
internetwork are involved, and the requirements are complex,
could be a lot of bits

(As a final aside, there's clearly no point in storing in the
any user state about packets which are providing datagram service
the datagram service has usually come and gone in the same packet
and this discussion is all about state retention.)

There are two schools of thought as to how to proceed. The first
that for reasons of robustness and simplicity, all user state
to be repeated in each packet. For efficiency reasons, the
may cache such user state, probably along with precomputed
derived from the user state. (It makes sense to store such
user state along with any applicable server state, of course.)

The second school says that if something is going to generate lots
packets, it makes engineering sense to give all this information
the routers once, and from then on have a tag (the flow-id) in
packet which tells the routers where to find that information. It'
simply going to be too inefficient to carry all the user state
all the time. This is purely an engineering efficiency reason,
it's a significant one

There is a slightly deeper argument, which says that the routers
inevitably come to contain more user state, and it's simply
question of whether that state is installed by an explicit mechanism
or whether the routers infer that state from watching the
which pass through them. To the extent that it is inevitable anyway
there are obvious benefits to be gained from recognizing that, and
explicit design of the installation is more likely to
satisfactory results (as opposed to an ad-hoc mechanism).

It is worth noting that although the term "flow" is often used
refer to this state in the routers along the path of the flow, it
important to distinguish between i) a flow as a sequence of
(i.e., the definition given in 3.2.2 above), and ii) a flow, as

Chiappa [Page 15]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

thing which is set up in the routers. They are different,
although the particular meaning is usually clear from the context
they are not the same thing at all

I'm not sure how much use there is to any intermediate position,
which one subsystem installs user state in the routers, and
carries a copy of its user state in each packet

(There are other intermediate positions. First, one flow might use
given technique for all its subsystems, and another flow might use
different technique for its; there is potentially some use to this
although I'm not sure the cost in complexity of supporting
mechanisms is worth the benefits. Second, one flow might use
mechanism with one router along its path, and another for a
router. A number of different reasons exist as to why one might
this, including the fact that not all routers may support the
mechanisms simultaneously.)

It seems to me that to have one internetwork layer subsystem (e.g.,
resource allocation) carry user state in all the packets (
with use of a "hint" in the packets to find potentially cached
in the router), and have a second (e.g., routing) use a
installation, and use a tag in the packets to find it, makes
sense. We should do one or the other, based on a consideration of
efficiency/robustness tradeoff

Also, if there is a way of installing such flow-associated state,
makes sense to have only one, which all subsystems use, instead
building a separate one for each flow

It's a little difficult to make the choice between installation,
carrying a copy in each packet, without more information of
how much user state the network is likely to have in the future. (
instance, we might wind up with 500 byte headers if we include
full source route, resource reservation, etc., in every header.)

It's also difficult without consideration of the actual
involved. As a general principle, we wish to make recovery from
loss of state as local as possible, to limit the number of
which have to become involved. (For instance, when a router crashes
traffic is rerouted around it without needing to open a new
connection.) The option of the "installation" looks a lot
attractive if it's simple, and relatively cheap, to reinstall
user state when a router crashes, without otherwise causing a lot
hassle

Chiappa [Page 16]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

However, given the likely growth in user state, the necessity
service state, the requirement for reliable installation, and
number of similar considerations, it seems that direct
of user state, and explicit recognition of flows, through a
definition and tag mechanism in the packets, is the way to go,
this is the path that Nimrod has chosen

3.3 Specific Interaction

Here is a very incomplete list of the things which Nimrod would
to see from the internetwork layer as a whole

- A unified definition of flows in the internetwork layer, and
unified way of identifying, through a separate flow-id field,
packets belong to a given flow

- A unified mechanism (potentially distributed) for installing
about flows (including multicast flows) in routers

- A method for getting information about whether a given
allocation request has failed along a given path; this might
part of the unified flow setup mechanism

- An interface to (potentially distributed) mechanism for
the membership in a multi-cast group

- Support for multiple interfaces; i.e., multi-homing. Nimrod
this by decoupling transport identification (done via EID's)
interface identification (done via locators). E.g., a packet
any valid destination locator should be accepted by the TCP of
endpoint, if the destination EID is the one assigned to
endpoint

- Support for multiple locators ("addresses") per network interface
This is needed for a number of reasons, among them to allow
less painful transitions in the locator abstraction hierarchy
the topology changes

- Support for multiple UID's ("addresses") per endpoint (roughly,
host). This would definitely include both multiple multicast SID's
and at least one unicast EID (the need for multiple unicast EID'
per endpoint is not obvious).

- Support for distinction between a multicast group as a
entity, and a multicast flow which may not reach all the members

- A distributed, replicated, user name translation system (DNS?)
maps such user names into (EID, locator0, ... locatorN) bindings

Chiappa [Page 17]

RFC 1753 Nimrod Technical Requirements for IPng December 1994

Security

Security issues are discussed in section 2.2.

Author's

J. Noel

Phone: (804) 898-8183
EMail: jnc@lcs.mit.

Chiappa [Page 18]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX