Project

General

Profile

NDNLPv2 » History » Version 5

Eric Newberry, 11/12/2016 10:15 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
Initially, the Sequence header field is defined:
53
54
    LpHeaderField ::= .. | Sequence
55
56
    Sequence ::= SEQUENCE-TYPE TLV-LENGTH
57
                   fixed-width unsigned integer
58
59
**Sequence** contains a sequence number that is useful in multiple features.
60
This field is REQUIRED if any enabled feature is using sequence numbers, otherwise it's OPTIONAL.
61
Bit width of the sequence is determined on a per-link basis; 8-octet is recommended for today's links.
62
A host MUST generate consecutive sequence numbers for outgoing packets on the same face.
63
64
    Fragment ::= FRAGMENT-TYPE TLV-LENGTH
65
                   byte+
66
67
**Fragment** contains a fragment of one or more network layer packets.
68
The fragmentation and reassembly feature defines how Fragment field is constructed and interpreted.
69
When fragmentation and reassembly feature is disabled, the Fragment field contains a whole network layer packet.
70
Fragment is OPTIONAL; LpPacket without Fragment is an **IDLE packet**.
71
72
## Indexed Fragmentation
73
74
Indexed fragmentation provides fragmentation and reassembly feature on datagram links that does not guarantee in-order delivery.
75
76
This feature defines two header fields:
77
78
    LpHeaderField ::= .. | FragIndex | FragCount
79
80
    FragIndex ::= FRAG-INDEX-TYPE TLV-LENGTH
81
                    nonNegativeInteger
82
83
    FragCount ::= FRAG-COUNT-TYPE TLV-LENGTH
84
                    nonNegativeInteger
85
86
Sender slices a network layer packet into one or more fragments.
87
The size of each fragment MUST be small enough so that the LpPacket carrying every fragment is below link MTU.
88
It is RECOMMENDED that all except the last fragments have the same size.
89
90
**FragCount** field indicates the number of fragments belonging to the same network layer packet.
91
It MUST be the same in all fragments belonging to the same network layer packet.
92
93
**FragIndex** field indicates the zero-based index of the current packet.
94
It MUST be assigned consecutively for fragments belonging to the same network layer packet, starting from zero.
95
The feature is named "indexed fragmentation" because every fragment is given an index in this field.
96
97
**Sequence** field is REQUIRED when this feature is enabled.
98
Fragments belonging to the same network layer packet MUST be assigned consecutive sequence numbers, in the same order with FragIndex.
99
100
For example, a 5000-octet network layer packet may be sliced as illustrated:
101
102
    +-------------+-------------+    +-------------+-------------+
103
    | LpPacket    | Fragment    |    | LpPacket    | Fragment    |
104
    | seq=8801    |             |    | seq=8802    |             |
105
    | FragIndex=0 | [0:1400]    |    | FragIndex=1 | [1400:2800] |
106
    | FragCount=4 |             |    | FragCount=4 |             |
107
    +-------------+-------------+    +-------------+-------------+
108
109
    +-------------+-------------+    +-------------+-------------+
110
    | LpPacket    | Fragment    |    | LpPacket    | Fragment    |
111
    | seq=8803    |             |    | seq=8804    |             |
112
    | FragIndex=2 | [2800:4200] |    | FragIndex=3 | [4200:5000] |
113
    | FragCount=4 |             |    | FragCount=4 |             |
114
    +-------------+-------------+    +-------------+-------------+
115
116
Receiver stores fragments in a *PartialMessageStore* data structure, which is a collection of PartialMessages, indexed by MessageIdentifier=Sequence-FragIndex.
117
Since both Sequence and FragIndex are assigned consecutively, MessageIdentifier would be the sequence number of the first fragment of a network layer packet.
118
After collecting all fragments belonging to a network layer packet, the receiver joins them together, and delivers the complete network layer packet to upper layer.
119
120
The receiver SHOULD maintain a reassembly timer in each PartialMessage, which is reset each time a new fragment is received.
121
If this timer expires, the PartialMessage is dropped.
122
Default duration for this timer is 500ms.
123
124
If this feature is enabled but FragIndex is missing, it is implied as zero.
125
If this feature is enabled but FragCount is missing, it is implied as one.
126
If this feature is disabled but either header field is received, the packet MUST be dropped.
127
128
Unless otherwise specified, header fields from other features shall only appear on the first fragment.
129
If a field appear on a non-first fragment, it MUST be ignored.
130
131
## Network NACK
132
133
A network NACK is a forwarding instruction from upstream to downstream that indicates the upstream is unable to satisfy an Interest.
134
135
This feature defines a header field:
136
137
    LpHeaderField ::= .. | Nack
138
139
    Nack ::= NACK-TYPE TLV-LENGTH
140
               NackReason?
141
142
    NackReason ::= NACK-REASON-TYPE TLV-LENGTH
143
                     nonNegativeInteger
144
145
**Nack** header field indicates an Interest is a NACK, and is not a normal Interest.
146
The receiver MUST NOT process the packet as an Interest.
147
148
**NackReason** element MAY be included to indicate why the NACK is transmitted.  
149
The following NackReason values are defined:
150
151
Code  | Reason       | Description
152
----- | ------------ | --------------------------------------------------------------
153
0     | None         | (reserved)
154
50    | Congestion   | there is a congestion in the link between upstream and downstream, or on the best-known path between upstream and content source
155
100   | Duplicate    | the upstream has detected a duplicate Nonce in the Interest sent by the downstream
156
150   | NoRoute      | the upstream has no path to reach a content source due to routing problem or link failure
157
158
A receiver MUST be prepared to process a NACK without a reason.  
159
If NackReason element contains an unrecognized reason, the receiver MUST treat this NACK as a NACK without reason, and MUST NOT drop the packet.
160
161
Example of NACK of an Interest for `/example` with NACK reason "Duplicate":
162
163
    +--------------------------+---------------+
164
    | LpPacket                 | Interest      |
165
    |                          | Name=/example |
166
    | +-Nack-----------------+ | Nonce=35      |
167
    | | NackReason=Duplicate | |               |
168
    | +----------------------+ |               |
169
    +--------------------------+---------------+
170
171
It's RECOMMENDED to enable this feature on every link.  
172
If this feature is disabled but Nack is received, the packet MUST be dropped.
173
174
Nack header field is permitted only on an LpPacket carrying an Interest.  
175
When Nack appears on an LpPacket carrying a network layer packet other than an Interest, the packet MUST be dropped.
176
177
## Consumer Controlled Forwarding
178
179
Consumer controlled forwarding allows a local consumer application to explicitly specify the nexthop face to forward an Interest.
180
181
This feature defines a header field:
182
183
    LpHeaderField ::= .. | NextHopFaceId
184
185
    NextHopFaceId ::= NEXT-HOP-FACE-ID-TYPE TLV-LENGTH
186
                        nonNegativeInteger
187
188
**NextHopFaceId** indicates the nexthop FaceId to which an Interest should be forwarded.
189
A local consumer application MAY add this field to an LpPacket carrying an Interest.
190
The local forwarder SHOULD follow this instruction and forward the Interest to the specified nexthop, after ContentStore lookup does not find a match.
191
192
This feature is designed to be used on local faces only.
193
It SHOULD NOT be enabled on non-local faces.
194
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.
195
If this feature is disabled but NextHopFaceId is received, the packet SHOULD be dropped, or this field MUST be ignored.
196
197
NextHopFaceId header field is permitted only on an LpPacket carrying an Interest, from an application to the forwarder.
198
When NextHopFaceId appears on an LpPacket carrying a network layer packet other than an Interest, the packet MUST be dropped.
199
When NextHopFaceId is received by an application from a forwarder, this field MUST be ignored.
200
201
## Local Cache Policy
202
203
Local cache policy feature allows a local producer application to instruct ContentStore on whether and how to cache a Data packet.
204
205
This feature defines a header field:
206
207
    LpHeaderField ::= .. | CachePolicy
208
209
    CachePolicy ::= CACHE-POLICY-TYPE TLV-LENGTH
210
                      CachePolicyType
211
212
    CachePolicyType ::= CACHE-POLICY-TYPE-TYPE TLV-LENGTH
213
                          nonNegativeInteger
214
215
**CachePolicy** header field gives a suggestion to the ContentStore.
216
The ContentStore MAY follow this suggestion.
217
218
**CachePolicyType** element MUST be included to indicate the suggestion.
219
The following CachePolicyType values are defined:
220
221
Code | Policy  | Description
222
-----|---------|--------------------------------
223
0    | None    | (reserved)
224
1    | NoCache | ContentStore SHOULD NOT admit the Data packet
225
226
If CachePolicyType field contains an unknown policy code, the forwarder SHOULD drop the packet.
227
228
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.
229
230
Example for a Data packet with "NoCache" policy:
231
232
    +-----------------------------+---------------+
233
    | LpPacket                    | Data          |
234
    |                             | Name=/example |
235
    | +-CachePolicy-------------+ | Content=xxxx  |
236
    | | CachePolicyType=NoCache | | Signature=xx  |
237
    | +-------------------------+ |               |
238
    +-----------------------------+---------------+
239
240
This feature is designed to be used on local faces only.
241
It SHOULD NOT be enabled on non-local faces.
242
If this feature is disabled but CachePolicy is received, this field MUST be ignored.
243
244
CachePolicy header field is permitted only on an LpPacket carrying a Data packet, from an application to the forwarder.
245
When CachePolicy header field appears on an LpPacket carrying a network layer packet other than a Data packet, the packet MUST be dropped.
246
When CachePolicy is received by an application from a forwarder, this field MUST be ignored.
247
248
## Incoming Face Indication
249
250
Incoming face indication feature allows the forwarder to inform local applications about the face on which a packet is received.
251
252
This feature defines a header field:
253
254
    LpHeaderField ::= .. | IncomingFaceId
255
256
    IncomingFaceId ::= INCOMING-FACE-ID-TYPE TLV-LENGTH
257
                         nonNegativeInteger
258
259
**IncomingFaceId** contains the FaceId from which the network layer packet is received.
260
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.
261
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.
262
Even if this feature is enabled, the application MUST be prepared to receive a packet without IncomingFaceId field.
263
264
This feature is designed to be used on local faces only.
265
It SHOULD NOT be enabled on non-local faces.
266
267
IncomingFaceId header field is permitted only on an LpPacket from the forwarder to an application.
268
When IncomingFaceId is received by the forwarder from an application, this field MUST be ignored.
269 1 Junxiao Shi
270 5 Eric Newberry
## Congestion Indication
271
272
A host can signal the current congestion state to other hosts using the **CongestionMark** field. The meaning of the bits in this field is left up to the congestion control strategy in use.
273
274
This features defines a header field:
275
276
    LpHeaderField ::= .. | CongestionMark
277
278
    CongestionMark ::= CONGESTION-MARK-TYPE TLV-LENGTH
279
                         nonNegativeInteger
280
281 2 Alex Afanasyev
## TLV-TYPE Code Assignments
282
283
 type            | code (decimal) | code (hexadecimal)
284
-----------------|----------------|--------------------
285
LpPacket         | 100            | 0x64
286
Fragment         | 80             | 0x50
287
Sequence         | 81             | 0x51
288
FragIndex        | 82             | 0x52
289
FragCount        | 83             | 0x53
290
Nack             | 800            | 0x0320
291
NackReason       | 801            | 0x0321
292 3 Davide Pesavento
NextHopFaceId    | 816            | 0x0330
293 2 Alex Afanasyev
IncomingFaceId   | 817            | 0x0331
294 1 Junxiao Shi
CachePolicy      | 820            | 0x0334
295 2 Alex Afanasyev
CachePolicyType  | 821            | 0x0335
296 5 Eric Newberry
CongestionMark   | 832            | 0x0340
297 2 Alex Afanasyev
298
### Reserved Blocks
299
300
Two blocks of TLV-TYPE codes have been reserved by link protocols:
301
302
* [80:100], 1-octet encoding
303
* [800:1000], 3-octet encoding
304
305
TLV-TYPE codes for LpHeaderField SHOULD be assigned according to the following rules:
306
307 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.
308
2. if the field would occur frequently, pick an unused code in the range [81:99].
309
3. otherwise, pick an unused code in the range [800:959] whose two least significant bits are 01.
310 2 Alex Afanasyev
311
Note: code assignment for a TLV-TYPE nested within a LpHeaderField is not restricted by the above rules.