Sketch of issues for strategy B:
Base layer 3 protocol - why not use IPv6 with the semantic that the "address" is -strictly- a locator and TCP/UDP are not valid for the address ranges used by strategy B.
Locator Assignment, Reassignment and Routing Protocol - to assign locators to hosts and networks.
Service name resolution protocl - to map names to their current locators
Connection oriented protocol
Connectionless protocol
Note that COP, CLP and SNRP should function over arbitrary layer-3's, not just the one provided by LARP. In particular, they should work over layer-3 IPv4 and IPv6.
Locator Assignment, Reassignment and Routing Protocl -
When a connection first comes up, if you have locators, send a message that says, "I have prefix X/Y from super prefix A/B distance Z."
Remote will respond with one of:
"I have prefix R/S from super prefix A/B distance Z." -- interior peer. Packets to and from X/Y and R/S can shortcut across this link.
"I have prefix R/S from super prefix A/B distance N<Z." -- Better upstream path. I will request locators from this link and deprecate X/Y.
"I want /S addresses." -- Link is downstream from me. If /S addresses are available, reply with an assignment. Otherwise, request a new larger assignment from upstream and then reply with an assignment /S in size. Also, if /S is bigger than the maximum allowed for that link, reject the request.
A link is either peering (P) or transit (T). If peering, it will not request of honor an "I want" message but it will route the destinations offered. Where does it propogate the peered addresses? Towards any interior peers and towards the origin of its prefixes.
If transit it may be parallel or not. If the link is designated to allow parallelism, then ask for /S addresses but don't give the ones on the alternate same-distance link up. When a downstream requests addresses, offer a prefix in both.
If you don't have addresses when the connection comes up, send a message which says, "I have no addresses. I want /S addressses."
A end host sends a multicast "I want /S addresses" when he comes up where /S is one.
Response to I want:
"Assign D/E from A/B distance Z to you. Assign F/G from A/B distance Z to you. Assign H/I from J/K distance L to you."
If multihomed you may get more than one. If its a parallel path to the same upstream ISP, they'll both be from the same super prefix. If its a different ISP, they won't.
Link failed:
If my upstream link fails, send a "X/Y no longer available" message to all links. Then pick the link that previously sent an I-have message with the lowest distance and send an "I want /s addresses."
Locators deprecated:
Send a message upstream that says, "Deprecate X/Y in C seconds." On the down stream side, send a message that says, "Assign D/E from A/B distance Z to you. Deprecate E/F (prior assignment) in C seconds." The downstream side should immedately register its new locators via SNRP and deprioritize the deprecated ones. After 1/2 C, it should remove the deprecated locators via SNRP. After C it should stop responding to packets with the old locators. After C, the upstream should stop routing E/F downstream and remove it from its table since it no longer holds that prefix.
Multihoming:
Accept a super-prefix from each upstream and propogate sub-prefixes downstream. Distance will be to the exit for that particular upstream.
Interface types:
1. Transit bidirectional. Will accept and/or offer addresses based on the distance to the source and will transmit routes towards the prefix sources. Use on interior links with more than one possible path to the ISP connections.
2. Transit accept. Will request and accept but won't offer addresses. Will transmit routes. Use on exterior links to an ISP.
3. Transit offer. Will offer but won't request or accept addresses. May accept routes. Use on exterior links to a customer.
4. Peer interior. Will accept and send shortcut routes for the owned prefixes. Will propogate them towards the prefix sources until they intersect. Not sure why you'd ever use this instead of transit bidirectional.
5. Peer exterior. Will accept and send super-prefix routes. Will propogate them towards the sources of the interior prefixes.
SNRP -
Name resolution -
DNS for the new protocols. A name identifies both a server and a service. It might be something like http:www.example.com. Also, make the name heriarchical character-by-character. The technical reasons for explicit seperators (like the ".") are long obsolete.
Because all destinations are based on names, you can't use a name-based layer-4 protocol to reach the name server. SNRP is a layer-4 protocol directly. This differs from DNS which sits on top of UDP.
Host sends a name request to an anycast locator assigned to "nearest resolver." Router expected to move it to a nearby resolver. Do we have more than one anycast locator or do we expect the router to figure out that the name server is dead and reroute to the next one? A combination of both?
Resolver machine sends a name request to an anycast locator assigned to "nearest root" server. Same issues as nearest resolver. Which anycast LOC(s) are "root dns" should be tunable in case folks want to run more than one DNS system.
Need an option in the query for "ignore cache." This is for when a client has discovered that a LOC has changed before the TTL expires. In this case the authoritative servers should be re-queried and the new results should replace the cached results. The server should still return the cached result to for other queries until the new result comes in just in case the request is lying or wrong.
Response is LOCs for request OR names for referal servers and any LOCs known for them. Recurse until you get the LOCs for the request.
A LOC record is cross between SRV and A/AAAA records. Components include:
Name registration -
Send a registration packet via anonymous connectionless protocol to the registration service at the name which matches your domain. Send another to clear a deprecated LOC or add a fresh LOC.
Standardize AAA for registrations or not? My hunch is create a AAA framework in the base protocol but no AAA mechanisms.
CLP -
Replaces UDP
Application passes a name to swap packets with. Uses SNRP to look up from nearest resolver.
All packets have a packet ID and get an ack indicating ID received An ack-now bit in the header controls whether an ack packet is sent immediately or after a timeout. Acks are options in the packet. The packet may also contiain payload. The packet can contain multiple acks; each packet must be acked seperately. A packet containing only acks need not be acked. Also have an option to set the milliseconds delay before acking packets without the acknow bit.
Application gives the API a callback for when an ack is received. App must decide what to do about retransmission if the acks don't come back.
CLP pays attention to the acks. If it doesn't see expected acks, it tries later packets from the app via a different source/dest LOC. CLP also repolls SNRP as needed to keep a LOC set under the TTL.
If a LOC changes for the host and an app on the host is holding a CLP session open, the target of the CLP session should be sent a CLP packet with an option that says, "refresh my name to LOC map." On receiving such a packet, the CLP host should re-request the service name with the ignore cache bit set. It should continue using its existing knowledge until the request returns.
Initiator starts in anonymous mode and selects a random session ID. The server may reject the session ID and suggest an alternative. Or it may fail to respond at all on that LOC. If it does, the client should try again and retransmit any packets until the server and client agree on the session ID and find mutually acceptable LOCs. This is the only time that CLP's layer-4 should retransmit on its own.
In anonymous mode, the server will respond on any LOCs from which the client has sent packets. There is no authentication of the client.
If the connection proves long-lived, the client may provide a service name for itself. At that point, the server will look up the name to find the client's authoritative list of LOCs. Once received, it will no longer use any LOC not listed for the name nor accept packets with that SID from a LOC not listed in the service name.
The server may send an option asking the client to upgrade to a named connection. If received, the client should initiate the named link immediately rather than waiting to see if the link persists.
Can't have a receive window option because layer-4 doesn't know what the app will do about retransmission and doesn't know which packets are retransmissions of earlier ones.
Might be useful to have a nak packet to indicate that the packet was received by the host but dropped due to no buffer?
Connection oriented protocol
Much like CLP. Differences:
Packet IDs will be sequential based on octets sent instead of random.
Ack packets will have the highest packet number before which everything has been received followed by any out of order packets. Unlike TCP, COP needs to know which packets were dropped and which were received in order to determine which LOC sets are dropped packets and which are working.
Layer-4 will automatically retransmit missing packets. It only needs to resend the dropped packets, not everything after the the last acked.
Have a receive window as well in each ack indicating the additional data (other than retransmits) that can be sent before the buffer is full.
Window size to be: 8 bit size, 8-bit scaler. Scaler is the number of binary zeros after the 8-bit size. App may treat any scaler larger than it supports as being the largest it supports.
Adust delay option for acks. If layer-4 notices its getting acks but they're late, it can advise the other side to adjust its delay expectation before retransmitting. Allows long, slow channels. Maybe?
Add in the other goodness from TCP that isn't otherwise damaged by the above.
What about forward error correction? Helpful to make this a standard part of the protocol from the outset?
Routing Test:
O: I want /32 from N
I am 1.0.0.23 of 1.0.0.23/32 of 1.0.0.0/27 to N
I am 1.0.0.27 of 1.0.0.27/32 of 1.0.0.0/27 to N
N: I want /31 from M,
I want /31 from L, I want /31 from K,
I want /31 from O: declined due to longer distance to all IPs
I want /31 from P: declined due to longer distance to all IPs
I am 1.0.0.74/31 of 1.0.0.0/25 to M distance 3
I am 1.0.0.70/31 of 1.0.0.0/25 to L distance 3
I am 2.0.0.78/31 of 2.0.0.0/25 to K distance 4
K: I want /30 from J
I am 2.0.0.76/30 of 2.0.0.0/25 to J distance 3
I am 1.0.0.124/30 of 1.0.0.0/25 to J distance 5
Route 0/0 to J distance 3
No grant 1.0.0.0/25 to N (longer)
Grant 2.0.0.78/31 to N
P: I want /32 from M
I want /32 from N
I am 1.0.0.73/32 of 1.0.0.0/25 to M distance 3
I am 2.0.0.121/32 of 2.0.0.0/25 to M distance 5
P should get a distance 5 grant of 2.0.0.0/25 from N
M: I want /30 from G
I want /30 from N: declined due to longer distance to all IPs
I am 1.0.0.72/30 of 1.0.0.0/25 to G distance 2
I am 2.0.0.120/30 of 2.0.0.0/25 to G distance 4
Route 0/0 to G distance 2
Grant 1.0.0.74/31 to N
No grant 2.0.0.122/31 to N (longer)
Grant 1.0.0.73/32 to P
Grant 2.0.0.121/32 to P
L: I want /30 from G
I want /30 from N: declined due to longer distance to all IPs
I am 1.0.0.68/30 of 1.0.0.0/25 to G distance 2
I am 2.0.0.116/30 of 2.0.0.0/25 to G distance 4
Route 0/0 to G distance 2
Grant 1.0.0.70/31 to N
Grant: 2.0.0.118/31 to N
G: I want /30+/30+/32+/27 =/26 from E
I want /28 from HI want from M: declined due to longer distance to all IPs
I want from L: declined due to longer distance to all IPs
I am 1.0.0.64/26 of 1.0.0.0/25 to E distance 1
Route 0/0 to E distance 1
I am 2.0.0.112/28 of 2.0.0.0/25 to H distance 3
Route 0/0 to H distance 3
Route 3.0.0.0/32 to F distance 2
Grant 1.0.0.68/30 to L
Grant 2.0.0.116/30 to L
Grant 1.0.0.72/30 to M
Grant 2.0.0.120/30 to M
Grant 1.0.0.96/27 to H
E: I want /26+/32=/25 from source
I am 1.0.0.0 of 1.0.0.0/25 of 0/0 distance 0
Grant 1.0.0.64/26 to G
F: I want /32 from source
I am 3.0.0.0/32 from source distance 0
Route 1.0.0.64/26 from G (how do I know this?)
Route 2.0.0.64/26 from G (how do I know this?)
H: I want /27 from I
I want /27 from GI am 2.0.0.96/27 of 2.0.0.0/25 to I distance 2
I am 1.0.0.96/27 to G distance 2
Route 0/0 to I distance 2
Route 0/0 to G distance 2
Route 3.0.0.0/32 to G distance 2
Grant 1.0.0.112/28 to I
J: I want /29 from I
I want /32 from K: declined, more distant
I am 2.0.0.72/29 to I distance 2
I am 1.0.0.120/29 to I distance 4
Route 0/0 to I distance 2
Grant 2.0.0.76/30 to K
Grant 1.0.0.124/30 to K
I: I want /32+/29+/27 = /26 from D
I want /28 from H
I want /26 from J
I am 2.0.0.64 of 2.0.0.64/26 if 2.0.0.0/25 to D distance 1
I am 1.0.0.112/28 to H distance 3
Route 0/0 to D distance 1
Roue 0/0 to H distance 3
Route 3.0.0.0/32 to H distance 3
Grant 2.0.0.96/27 to H
Grant 2.0.0.72/29 to J
D: I want /25 from source
I am 2.0.0.0 of 2.0.0.0/25 of 0/0 distance 0
A router always wants a single address first, regardless of what anyone else wants from him. Once he has an address, he can accept requests from neighbors and hosts and expand his want. This avoids an infinitely expanding want loop.