Update identification and length
Robert Woody Woodburn <woody@sparta.com> Sat, 02 May 1992 16:52 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa00571;
2 May 92 12:52 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa19916;
2 May 92 12:57 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa19912;
2 May 92 12:57 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa09846;
2 May 92 12:24 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa09842; 2 May 92 12:22 EDT
Received: from SPARTA.COM by BBN.COM id aa29147; 2 May 92 12:22 EDT
Received: from worf.SPARTA.COM by sparta.com (5.65/1.34)
id AA26685; Sat, 2 May 92 12:26:39 -0400
Received: by worf.sparta.com (5.65/1.34)
id AA02511; Sat, 2 May 92 12:26:32 -0400
Date: Sat, 2 May 92 12:26:32 -0400
From: Robert Woody Woodburn <woody@sparta.com>
Message-Id: <9205021626.AA02511@worf.sparta.com>
To: idpr-wg@bbn.com
Subject: Update identification and length
In reimplementing update, I've noticed that the only key identifying an
update are its AD number and its component. This may become a problem in
the future, merely because the length of updates could grow very large,
large enough to exceed the MTU of most networks. It would be nice to
avoid fragmentation.
Because there is not an explicit distinguishing attribute that would allow
multiple updates to describe an AD, the format would have to be changed
to either have a single PT/update or allow some combination. This won't
be a problem with the initial implementation, since ADs won't have very
complex policies or large numbers of VGs, etc, that could make them huge.
The first most immediate solution would be to have one update per
policy term, with the policy term number becoming a distinguishing
attribute. However, even a single PT can become quite large and I'm
wondering if there shouldn't be something like a segment identifier.
Rather than reinventing the wheel, we may have to think about TCP.
I haven't thought through just how big an individual PT could get, but
certainly the existing structure may have problems being broken up.
This leads to another suggestion. How about simply making the message
format more generic by doing something similar to what BGP does with
attributes. In otherwords, rather than the rigid message format, there
would be 5 attribute types:
AD Group
Time Spec
UCI
Offered Service
VG Group
These items could appear in any order with the message format changing
to look something like:
NOTE: Everything is padded to the nearest short word when needed.
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD CMP | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM TP | RS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP | NUM ATTR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: This still doesn't answer the problem of jumbo policies or now to
distinguish updates that have been broken into several pieces.
And then for each attribute:
AD Group:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR | NUM AD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD0 | NUM HSET | HSET0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HSET1 | ... | HSETN | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADN | NUM HSET | HSET0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HSET1 | ... | HSETN | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Time Spec:
NOTE: DURATION and START require special processing because they
do not fall on short word boundaries.
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR | TM FLGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DURATION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| START |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PERIOD | ACTIVE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UCI:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR | UCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Offered Service:
/* offered services are variable length to begin with. I would suggest */
/* that each offered service be an independently defined attribute: */
Delay:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR | DELAY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Delay Standard Deviation:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR | DELAY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Avail Bandwidth:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BAND-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
WIDTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
( 4 Gbps probably won't be enough, but I do hope 281,474,976,710,655 bps
will hast us into the next decade ;)
Bandwidth Standard Deviation:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH STANDARD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DEVIATION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MTU in bytes:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
( I hope Gb packets will be big enough over those Qb links! ;-)
Charging Method:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR | Charging Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tariff:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR | Tariff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VG Group:
0 8 16 24 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATTR | NUM VG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VG0 | VG FLGS | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VGN | VG FLGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
wood y
- Update identification and length Robert Woody Woodburn
- Update identification and length yakov
- Update identification and length Robert Woody Woodburn
- Re: Update identification and length barns