Project

General

Profile

NDNLPv2 » History » Version 14

Davide Pesavento, 04/05/2017 08:47 PM

1 1 Junxiao Shi
<script src="https://gist.github.com/yoursunny/92d8c3514476be6a7b93.js"></script>
2 2 Alex Afanasyev
3
# NDNLPv2
4
5
NDNLPv2 is a link protocol for [Named Data Networking](http://named-data.net/).
6
7
## Goals
8
9
NDNLPv2 provides the following **features**:
10
11
* fragmentation and reassembly: fragment a network layer packet to fit in link MTU
12
* failure detection: rapidly detect link failure and recovery
13
* reliability: reduce packet loss
14
* integrity: prevent packet injection
15
* forwarding instruction: NACK, nexthop choice, cache control, etc
16
* packet information: for management and monitoring
17
18
NDNLPv2 is designed to be a **unified protocol** that can be used on all kinds of links, including but not limited to: UNIX sockets, Ethernet unicast/multicast, UDP unicast/multicast, TCP connections, WebSockets, etc.
19
20
NDNLPv2 protocol operates as a **link adaptation layer**; it is above link layer and below network layer.
21
Please, do not call this "layer 2.5": there is no such notion in RFC protocols.
22
23
Different links need different features, or different designs of a feature.
24
NDNLPv2 ensures **all features are optional** and can be turned on or off per-link.
25
NDNLPv2 also allows different designs of a feature to be adopted per-link.
26
27
NDNLPv2 deprecates and replaces: [original NDNLP (aka NDNLPv1)](http://named-data.net/publications/techreports/trlinkprotocol/), [NDNLPv1 multicast extension](https://github.com/NDN-Routing/NDNFD/blob/master/docs/NDNLP.md), [NDNLPv1-TLV](http://redmine.named-data.net/projects/nfd/wiki/NDNLP-TLV/7), [NDNLP-BFD](http://redmine.named-data.net/attachments/download/231/NDNLP-BFDSummaryReport.pdf), [NFD LocalControlHeader](http://redmine.named-data.net/projects/nfd/wiki/LocalControlHeader/25).
28
29
## NDNLP Packet Format
30
31
NDNLPv2 packet adopts a Type-Length-Value (TLV) structure similar to [NDN Packet Format](http://named-data.net/doc/ndn-tlv/tlv.html).
32
33
    LpPacket ::= LP-PACKET-TYPE TLV-LENGTH
34
                   LpHeaderField*
35
                   Fragment?
36
37
Outermost packet transmitted on a NDNLPv2 link is LpPacket.
38
In addition, a host MUST also accept bare network packets (Interest and Data) on a NDNLPv2 link, which SHOULD be interpreted as an LpPacket with the bare network packet as its LpFragment. However, such packets could be dropped later in processing if the link configured to require a certain NDNLPv2 feature but a field is missing.
39
40
**LpHeaderField** is a repeatable optional structure in LpHeader.
41
NDNLPv2 features MAY add new header fields by extending the definition of LpHeaderField.
42
Unless otherwise specified, the same field shall appear at most once.
43
Unless otherwise specified, fields MUST appear in the order of increasing TLV-TYPE codes.
44
45
If an incoming LpPacket contains an unknown LpHeaderField, the following rules apply:
46
47 5 Eric Newberry
1. if the unknown field is in range [800:959], and the two least significant bits are 00, the receive SHOULD ignore the field, and continue processing the packet;
48 2 Alex Afanasyev
2. otherwise, the receiver MUST drop the packet, but SHOULD NOT consider the link has an error.
49
50
Note: if a field is recognized but the relevant feature is disabled, it's not an "unknown field".
51
52
    LpHeaderField ::= .. | Sequence
53
54
    Sequence ::= SEQUENCE-TYPE TLV-LENGTH
55
                   fixed-width unsigned integer
56
57
**Sequence** contains a sequence number that is useful in multiple features.
58
This field is REQUIRED if any enabled feature is using sequence numbers, otherwise it's OPTIONAL.
59
Bit width of the sequence is determined on a per-link basis; 8-octet is recommended for today's links.
60
A host MUST generate consecutive sequence numbers for outgoing packets on the same face.
61
62
    Fragment ::= FRAGMENT-TYPE TLV-LENGTH
63
                   byte+
64
65
**Fragment** contains a fragment of one or more network layer packets.
66 1 Junxiao Shi
The fragmentation and reassembly feature defines how Fragment field is constructed and interpreted.
67 2 Alex Afanasyev
When fragmentation and reassembly feature is disabled, the Fragment field contains a whole network layer packet.
68 14 Davide Pesavento
Fragment is OPTIONAL; an LpPacket without Fragment is an **IDLE packet**.
69 1 Junxiao Shi
70 2 Alex Afanasyev
## Indexed Fragmentation
71
72 14 Davide Pesavento
Indexed fragmentation provides fragmentation and reassembly feature on datagram links that do not guarantee in-order delivery.
73 2 Alex Afanasyev
74
This feature defines two header fields:
75
76
    LpHeaderField ::= .. | FragIndex | FragCount
77
78
    FragIndex ::= FRAG-INDEX-TYPE TLV-LENGTH
79
                    nonNegativeInteger
80 1 Junxiao Shi
81
    FragCount ::= FRAG-COUNT-TYPE TLV-LENGTH
82 2 Alex Afanasyev
                    nonNegativeInteger
83
84 14 Davide Pesavento
The sender slices a network layer packet into one or more fragments.
85
The size of each fragment MUST be small enough so that the LpPacket carrying every fragment is below the link MTU.
86 2 Alex Afanasyev
It is RECOMMENDED that all except the last fragments have the same size.
87
88
**FragCount** field indicates the number of fragments belonging to the same network layer packet.
89
It MUST be the same in all fragments belonging to the same network layer packet.
90
91
**FragIndex** field indicates the zero-based index of the current packet.
92
It MUST be assigned consecutively for fragments belonging to the same network layer packet, starting from zero.
93
The feature is named "indexed fragmentation" because every fragment is given an index in this field.
94
95
**Sequence** field is REQUIRED when this feature is enabled.
96
Fragments belonging to the same network layer packet MUST be assigned consecutive sequence numbers, in the same order with FragIndex.
97
98
For example, a 5000-octet network layer packet may be sliced as illustrated:
99
100
    +-------------+-------------+    +-------------+-------------+
101
    | LpPacket    | Fragment    |    | LpPacket    | Fragment    |
102
    | seq=8801    |             |    | seq=8802    |             |
103
    | FragIndex=0 | [0:1400]    |    | FragIndex=1 | [1400:2800] |
104
    | FragCount=4 |             |    | FragCount=4 |             |
105
    +-------------+-------------+    +-------------+-------------+
106
107
    +-------------+-------------+    +-------------+-------------+
108 1 Junxiao Shi
    | LpPacket    | Fragment    |    | LpPacket    | Fragment    |
109 2 Alex Afanasyev
    | seq=8803    |             |    | seq=8804    |             |
110
    | FragIndex=2 | [2800:4200] |    | FragIndex=3 | [4200:5000] |
111
    | FragCount=4 |             |    | FragCount=4 |             |
112
    +-------------+-------------+    +-------------+-------------+
113 1 Junxiao Shi
114 14 Davide Pesavento
The receiver stores fragments in a *PartialMessageStore* data structure, which is a collection of PartialMessages, indexed by MessageIdentifier=Sequence-FragIndex.
115 1 Junxiao Shi
Since both Sequence and FragIndex are assigned consecutively, MessageIdentifier would be the sequence number of the first fragment of a network layer packet.
116 14 Davide Pesavento
After collecting all fragments belonging to a network layer packet, the receiver stitches them together, and delivers the complete network layer packet to the upper layer.
117 2 Alex Afanasyev
118 14 Davide Pesavento
The receiver SHOULD maintain a reassembly timer for each PartialMessage, which is reset each time a new fragment is received.
119 2 Alex Afanasyev
If this timer expires, the PartialMessage is dropped.
120 14 Davide Pesavento
The default duration of this timer is 500ms.
121 2 Alex Afanasyev
122 14 Davide Pesavento
If this feature is enabled but FragIndex is missing, it is assumed to be 0 (zero).
123
If this feature is enabled but FragCount is missing, it is assumed to be 1 (one).
124 2 Alex Afanasyev
If this feature is disabled but either header field is received, the packet MUST be dropped.
125
126 14 Davide Pesavento
Unless otherwise specified, header fields from other features MUST appear only in the first fragment.
127
If a header field appears on a subsequent fragment, it MUST be ignored, unless otherwise specified.
128 2 Alex Afanasyev
129
## Network NACK
130
131
A network NACK is a forwarding instruction from upstream to downstream that indicates the upstream is unable to satisfy an Interest.
132
133
This feature defines a header field:
134
135
    LpHeaderField ::= .. | Nack
136
137
    Nack ::= NACK-TYPE TLV-LENGTH
138
               NackReason?
139
140
    NackReason ::= NACK-REASON-TYPE TLV-LENGTH
141
                     nonNegativeInteger
142
143
**Nack** header field indicates an Interest is a NACK, and is not a normal Interest.
144
The receiver MUST NOT process the packet as an Interest.
145
146
**NackReason** element MAY be included to indicate why the NACK is transmitted.  
147
The following NackReason values are defined:
148
149
Code  | Reason       | Description
150
----- | ------------ | --------------------------------------------------------------
151
0     | None         | (reserved)
152
50    | Congestion   | there is a congestion in the link between upstream and downstream, or on the best-known path between upstream and content source
153
100   | Duplicate    | the upstream has detected a duplicate Nonce in the Interest sent by the downstream
154
150   | NoRoute      | the upstream has no path to reach a content source due to routing problem or link failure
155
156
A receiver MUST be prepared to process a NACK without a reason.  
157
If NackReason element contains an unrecognized reason, the receiver MUST treat this NACK as a NACK without reason, and MUST NOT drop the packet.
158
159
Example of NACK of an Interest for `/example` with NACK reason "Duplicate":
160
161
    +--------------------------+---------------+
162
    | LpPacket                 | Interest      |
163
    |                          | Name=/example |
164
    | +-Nack-----------------+ | Nonce=35      |
165
    | | NackReason=Duplicate | |               |
166
    | +----------------------+ |               |
167
    +--------------------------+---------------+
168
169
It's RECOMMENDED to enable this feature on every link.  
170
If this feature is disabled but Nack is received, the packet MUST be dropped.
171
172
Nack header field is permitted only on an LpPacket carrying an Interest.  
173
When Nack appears on an LpPacket carrying a network layer packet other than an Interest, the packet MUST be dropped.
174
175 13 Davide Pesavento
## Consumer-Controlled Forwarding
176 2 Alex Afanasyev
177 13 Davide Pesavento
Consumer-controlled forwarding allows a local consumer application to explicitly specify the nexthop face to forward an Interest.
178 2 Alex Afanasyev
179
This feature defines a header field:
180
181
    LpHeaderField ::= .. | NextHopFaceId
182
183
    NextHopFaceId ::= NEXT-HOP-FACE-ID-TYPE TLV-LENGTH
184
                        nonNegativeInteger
185
186
**NextHopFaceId** indicates the nexthop FaceId to which an Interest should be forwarded.
187
A local consumer application MAY add this field to an LpPacket carrying an Interest.
188
The local forwarder SHOULD follow this instruction and forward the Interest to the specified nexthop, after ContentStore lookup does not find a match.
189
190
This feature is designed to be used on local faces only.
191
It SHOULD NOT be enabled on non-local faces.
192
If this feature is enabled but NextHopFaceId refers to a non-existent face, the Interest SHOULD be processed as if there is no available route.
193
If this feature is disabled but NextHopFaceId is received, the packet SHOULD be dropped, or this field MUST be ignored.
194
195
NextHopFaceId header field is permitted only on an LpPacket carrying an Interest, from an application to the forwarder.
196
When NextHopFaceId appears on an LpPacket carrying a network layer packet other than an Interest, the packet MUST be dropped.
197
When NextHopFaceId is received by an application from a forwarder, this field MUST be ignored.
198
199
## Local Cache Policy
200
201
Local cache policy feature allows a local producer application to instruct ContentStore on whether and how to cache a Data packet.
202
203
This feature defines a header field:
204
205
    LpHeaderField ::= .. | CachePolicy
206
207
    CachePolicy ::= CACHE-POLICY-TYPE TLV-LENGTH
208
                      CachePolicyType
209
210
    CachePolicyType ::= CACHE-POLICY-TYPE-TYPE TLV-LENGTH
211
                          nonNegativeInteger
212
213
**CachePolicy** header field gives a suggestion to the ContentStore.
214
The ContentStore MAY follow this suggestion.
215
216
**CachePolicyType** element MUST be included to indicate the suggestion.
217
The following CachePolicyType values are defined:
218
219
Code | Policy  | Description
220
-----|---------|--------------------------------
221
0    | None    | (reserved)
222
1    | NoCache | ContentStore SHOULD NOT admit the Data packet
223
224
If CachePolicyType field contains an unknown policy code, the forwarder SHOULD drop the packet.
225
226
The design places the policy code in the CachePolicyType element nested under CachePolicy, instead of having the code appear directly in CachePolicy header field, because in the future other policies that require additional arguments can be defined, and those arguments can appear as elements after CachePolicyType.
227
228
Example for a Data packet with "NoCache" policy:
229
230
    +-----------------------------+---------------+
231
    | LpPacket                    | Data          |
232
    |                             | Name=/example |
233
    | +-CachePolicy-------------+ | Content=xxxx  |
234
    | | CachePolicyType=NoCache | | Signature=xx  |
235
    | +-------------------------+ |               |
236
    +-----------------------------+---------------+
237
238
This feature is designed to be used on local faces only.
239
It SHOULD NOT be enabled on non-local faces.
240
If this feature is disabled but CachePolicy is received, this field MUST be ignored.
241
242
CachePolicy header field is permitted only on an LpPacket carrying a Data packet, from an application to the forwarder.
243
When CachePolicy header field appears on an LpPacket carrying a network layer packet other than a Data packet, the packet MUST be dropped.
244
When CachePolicy is received by an application from a forwarder, this field MUST be ignored.
245
246
## Incoming Face Indication
247
248
Incoming face indication feature allows the forwarder to inform local applications about the face on which a packet is received.
249
250
This feature defines a header field:
251
252
    LpHeaderField ::= .. | IncomingFaceId
253
254
    IncomingFaceId ::= INCOMING-FACE-ID-TYPE TLV-LENGTH
255
                         nonNegativeInteger
256
257
**IncomingFaceId** contains the FaceId from which the network layer packet is received.
258
When this feature is enabled, the forwarder SHOULD attach this field to every network layer packet going to a local application, and indicate the FaceId on which this network layer packet is received by the forwarder.
259
If a Data packet comes from the ContentStore, IncomingFaceId SHOULD contain a special FaceId that represents the ContentStore, rather than the FaceId on which this Data packet was originally received.
260
Even if this feature is enabled, the application MUST be prepared to receive a packet without IncomingFaceId field.
261
262
This feature is designed to be used on local faces only.
263
It SHOULD NOT be enabled on non-local faces.
264
265
IncomingFaceId header field is permitted only on an LpPacket from the forwarder to an application.
266
When IncomingFaceId is received by the forwarder from an application, this field MUST be ignored.
267 1 Junxiao Shi
268 6 Eric Newberry
## Congestion Marks
269 5 Eric Newberry
270 7 Anonymous
A host can signal the current congestion state to other hosts using the **CongestionMark** field. A value of 0 indicates *no congestion*; a value greater than 0 indicates some level of congestion. The exact meaning of the bits in this field is left up to the congestion control strategy in use.
271 5 Eric Newberry
272
This features defines a header field:
273 1 Junxiao Shi
274 5 Eric Newberry
    LpHeaderField ::= .. | CongestionMark
275
276 1 Junxiao Shi
    CongestionMark ::= CONGESTION-MARK-TYPE TLV-LENGTH
277 5 Eric Newberry
                         nonNegativeInteger
278
279 9 Eric Newberry
## Link Layer Reliability
280
281 10 Eric Newberry
To provide increased reliability and indicate potential congestion on a unicast link, a sender can expect frames successfully received by another host to be acknowledged.
282 9 Eric Newberry
283 11 Eric Newberry
After sending a link-layer frame (potentially fragmented, as described above), a host will expect an Ack field to be received on a frame returned in the opposite direction. This field will contain the TxSequence of the acknowledged frame. TxSequence numbers are assigned sequentially on the link, and are independent of the sequence number of the stored fragment. If the host does not receive this acknowledgement within the RTO (determined using the formula described below) and the frame has not been retransmitted more than a pre-determined number of times (the maximum number of retransmissions), the frame will be retransmitted on the link with the same sequence number, but a new TxSequence. In addition, if a configurable number of Acks (three by default) for greater TxSequences are received by the sender of the frame, the frame will be considered lost and the previously discussed retransmission logic will be followed.
284 9 Eric Newberry
285
Every time a frame is retransmitted, a notification signal (`onLoss()`) will be called to alert the forwarding strategy that the link may be congested. If a frame exceeds the maximum number of retransmissions, a different notification signal (`onGiveUp()`) will be used.
286
287 14 Davide Pesavento
To facilitate the retransmission of frames, each frame will be cached on the sender until it is acknowledged, at which point it can be deleted from the cache. The sender also keeps track of which frames were fragmented from which network-layer packet (if fragmentation occurred) and which unacknowledged TxSequences reference which transmitted frame. If one fragment of a network-layer packet exceeds the maximum number of retransmissions, the RTO timers of all fragments in the packet will be cancelled, all fragments of the packet will be deleted from the frame cache, and the entire packet will be considered lost. The sender will keep track of which sequence numbers are associated with which network-layer packets.
288 9 Eric Newberry
289 11 Eric Newberry
The receiver will extract the TxSequence of every received frame and will insert these numbers into a queue of pending Acks destined for the sender, along with the time the TxSequence was added. When a frame is being transmitted in the opposite direction, any excess space under the MTU will be filled with TxSequences removed from this queue. In order to handle links that have gone idle, every 5ms (or another configurable non-zero time period), as many Acks as can fit in a single IDLE frame will be sent on the link.
290 9 Eric Newberry
291 14 Davide Pesavento
The RTO is determined using the standard TCP formula: `RTO = SRTT + 4 * RTTVAR`. The round-trip time (RTT) of a packet is measured as the difference between the time the frame was transmitted and when an Ack was received for it. Frames that have been retransmitted are not taken into account by this formula.
292 9 Eric Newberry
293 11 Eric Newberry
Multiple Ack fields can be sent in one LpPacket. If an Ack is received for an unknown TxSequence, the Ack will be ignored.
294 9 Eric Newberry
295 12 Eric Newberry
    LpHeaderField ::= .. | TxSequence | Ack
296
297
    TxSequence ::= TX-SEQUENCE-TYPE TLV-LENGTH
298
                     fixed-width unsigned integer
299 9 Eric Newberry
300
    Ack ::= ACK-TYPE TLV-LENGTH
301
              fixed-width unsigned integer
302
303
**Modified from "Hop-By-Hop Best Effort Link Layer Reliability in Named Data Networking" by S. Vusirikala, et al.**
304
305 2 Alex Afanasyev
## TLV-TYPE Code Assignments
306
307
 type            | code (decimal) | code (hexadecimal)
308
-----------------|----------------|--------------------
309
LpPacket         | 100            | 0x64
310
Fragment         | 80             | 0x50
311
Sequence         | 81             | 0x51
312
FragIndex        | 82             | 0x52
313
FragCount        | 83             | 0x53
314 8 Alex Afanasyev
HopCount (ndnSIM) | 84 | 0x54
315 2 Alex Afanasyev
Nack             | 800            | 0x0320
316
NackReason       | 801            | 0x0321
317 3 Davide Pesavento
NextHopFaceId    | 816            | 0x0330
318 1 Junxiao Shi
IncomingFaceId   | 817            | 0x0331
319 2 Alex Afanasyev
CachePolicy      | 820            | 0x0334
320 1 Junxiao Shi
CachePolicyType  | 821            | 0x0335
321 2 Alex Afanasyev
CongestionMark   | 832            | 0x0340
322 5 Eric Newberry
Ack              | 836            | 0x0344
323 11 Eric Newberry
TxSequence       | 840            | 0x0348
324 2 Alex Afanasyev
325
### Reserved Blocks
326
327
Two blocks of TLV-TYPE codes have been reserved by link protocols:
328
329
* [80:100], 1-octet encoding
330
* [800:1000], 3-octet encoding
331
332
TLV-TYPE codes for LpHeaderField SHOULD be assigned according to the following rules:
333
334 3 Davide Pesavento
1. if the field can be safely ignored by a receiver that doesn't understand the field, pick an unused code in the range [800:959] whose two least significant bits are 00.
335
2. if the field would occur frequently, pick an unused code in the range [81:99].
336
3. otherwise, pick an unused code in the range [800:959] whose two least significant bits are 01.
337 2 Alex Afanasyev
338
Note: code assignment for a TLV-TYPE nested within a LpHeaderField is not restricted by the above rules.