Project

General

Profile

NDNLPv2 » History » Version 48

Davide Pesavento, 06/19/2019 09:46 AM

1 47 Junxiao Shi
2 1 Junxiao Shi
# NDNLPv2
3 2 Alex Afanasyev
4 45 Davide Pesavento
{{>toc}}
5
6 16 Junxiao Shi
NDNLPv2 is a link protocol for [Named Data Networking](https://named-data.net/).
7 2 Alex Afanasyev
8
## Goals
9
10
NDNLPv2 provides the following **features**:
11
12
* fragmentation and reassembly: fragment a network layer packet to fit in link MTU
13
* failure detection: rapidly detect link failure and recovery
14
* reliability: reduce packet loss
15
* integrity: prevent packet injection
16
* forwarding instruction: NACK, nexthop choice, cache control, etc
17
* packet information: for management and monitoring
18
19
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.
20
21
NDNLPv2 protocol operates as a **link adaptation layer**; it is above link layer and below network layer.
22
Please, do not call this "layer 2.5": there is no such notion in RFC protocols.
23
24
Different links need different features, or different designs of a feature.
25 1 Junxiao Shi
NDNLPv2 ensures **all features are optional** and can be turned on or off per-link.
26 2 Alex Afanasyev
NDNLPv2 also allows different designs of a feature to be adopted per-link.
27
28 16 Junxiao Shi
NDNLPv2 deprecates and replaces: [original NDNLP (aka NDNLPv1)](https://named-data.net/publications/techreports/trlinkprotocol/), [NDNLPv1 multicast extension](https://github.com/NDN-Routing/NDNFD/blob/master/docs/NDNLP.md), [NDNLPv1-TLV](https://redmine.named-data.net/projects/nfd/wiki/NDNLP-TLV/7), [NDNLP-BFD](https://redmine.named-data.net/attachments/download/231/NDNLP-BFDSummaryReport.pdf), [NFD LocalControlHeader](https://redmine.named-data.net/projects/nfd/wiki/LocalControlHeader/25).
29 2 Alex Afanasyev
30
## NDNLP Packet Format
31
32 46 Davide Pesavento
NDNLPv2 packet adopts a Type-Length-Value (TLV) structure similar to [NDN Packet Format](https://named-data.net/doc/NDN-packet-spec/current/tlv.html).
33 1 Junxiao Shi
34 47 Junxiao Shi
    LpPacket = LP-PACKET-TYPE TLV-LENGTH
35
                 *LpHeaderField
36
                 [Fragment]
37 17 Davide Pesavento
38 47 Junxiao Shi
    LpHeaderField = Sequence
39 17 Davide Pesavento
40 47 Junxiao Shi
    Sequence = SEQUENCE-TYPE TLV-LENGTH 8OCTET
41 17 Davide Pesavento
42 47 Junxiao Shi
    Fragment = FRAGMENT-TYPE TLV-LENGTH 1*OCTET
43 17 Davide Pesavento
44 2 Alex Afanasyev
Outermost packet transmitted on a NDNLPv2 link is LpPacket.
45 16 Junxiao Shi
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 Fragment. However, such packets could be dropped later in processing if the link configured to require a certain NDNLPv2 feature but a field is missing.
46 2 Alex Afanasyev
47
**LpHeaderField** is a repeatable optional structure in LpHeader.
48
NDNLPv2 features MAY add new header fields by extending the definition of LpHeaderField.
49
Unless otherwise specified, the same field shall appear at most once.
50
Unless otherwise specified, fields MUST appear in the order of increasing TLV-TYPE codes.
51
52
If an incoming LpPacket contains an unknown LpHeaderField, the following rules apply:
53
54 27 Davide Pesavento
1. if the unknown field is in the range `[800, 959]` and the two least significant bits are both zero, the receiver SHOULD ignore the field and continue processing the packet;
55 2 Alex Afanasyev
2. otherwise, the receiver MUST drop the packet, but SHOULD NOT consider the link has an error.
56
57 27 Davide Pesavento
Note: if a field is recognized but the relevant feature is disabled, it's not considered "unknown".
58 2 Alex Afanasyev
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 48 Davide Pesavento
Bit width of the sequence number is determined on a per-link basis, 8 octets are recommended for today's links.
62 2 Alex Afanasyev
A host MUST generate consecutive sequence numbers for outgoing packets on the same face.
63
64
**Fragment** contains a fragment of one or more network layer packets.
65 1 Junxiao Shi
The fragmentation and reassembly feature defines how Fragment field is constructed and interpreted.
66 2 Alex Afanasyev
When fragmentation and reassembly feature is disabled, the Fragment field contains a whole network layer packet.
67 1 Junxiao Shi
Fragment is OPTIONAL; an LpPacket without Fragment is an **IDLE packet**.
68
69 2 Alex Afanasyev
## Indexed Fragmentation
70
71
Indexed fragmentation provides fragmentation and reassembly feature on datagram links that do not guarantee in-order delivery.
72
73
This feature defines two header fields:
74
75 47 Junxiao Shi
    LpHeaderField =/ FragIndex / FragCount
76 2 Alex Afanasyev
77 47 Junxiao Shi
    FragIndex = FRAG-INDEX-TYPE TLV-LENGTH nonNegativeInteger
78 1 Junxiao Shi
79 47 Junxiao Shi
    FragCount = FRAG-COUNT-TYPE TLV-LENGTH nonNegativeInteger
80 2 Alex Afanasyev
81 14 Davide Pesavento
The sender slices a network layer packet into one or more fragments.
82
The size of each fragment MUST be small enough so that the LpPacket carrying every fragment is below the link MTU.
83 2 Alex Afanasyev
It is RECOMMENDED that all except the last fragments have the same size.
84
85
**FragCount** field indicates the number of fragments belonging to the same network layer packet.
86
It MUST be the same in all fragments belonging to the same network layer packet.
87
88
**FragIndex** field indicates the zero-based index of the current packet.
89
It MUST be assigned consecutively for fragments belonging to the same network layer packet, starting from zero.
90
The feature is named "indexed fragmentation" because every fragment is given an index in this field.
91
92
**Sequence** field is REQUIRED when this feature is enabled.
93
Fragments belonging to the same network layer packet MUST be assigned consecutive sequence numbers, in the same order with FragIndex.
94
95
For example, a 5000-octet network layer packet may be sliced as illustrated:
96
97
    +-------------+-------------+    +-------------+-------------+
98
    | LpPacket    | Fragment    |    | LpPacket    | Fragment    |
99
    | seq=8801    |             |    | seq=8802    |             |
100
    | FragIndex=0 | [0:1400]    |    | FragIndex=1 | [1400:2800] |
101
    | FragCount=4 |             |    | FragCount=4 |             |
102
    +-------------+-------------+    +-------------+-------------+
103
104
    +-------------+-------------+    +-------------+-------------+
105 1 Junxiao Shi
    | LpPacket    | Fragment    |    | LpPacket    | Fragment    |
106 2 Alex Afanasyev
    | seq=8803    |             |    | seq=8804    |             |
107
    | FragIndex=2 | [2800:4200] |    | FragIndex=3 | [4200:5000] |
108
    | FragCount=4 |             |    | FragCount=4 |             |
109
    +-------------+-------------+    +-------------+-------------+
110 1 Junxiao Shi
111 14 Davide Pesavento
The receiver stores fragments in a *PartialMessageStore* data structure, which is a collection of PartialMessages, indexed by MessageIdentifier=Sequence-FragIndex.
112 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.
113 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.
114 2 Alex Afanasyev
115 14 Davide Pesavento
The receiver SHOULD maintain a reassembly timer for each PartialMessage, which is reset each time a new fragment is received.
116 2 Alex Afanasyev
If this timer expires, the PartialMessage is dropped.
117 14 Davide Pesavento
The default duration of this timer is 500ms.
118 2 Alex Afanasyev
119 1 Junxiao Shi
If this feature is enabled but FragIndex is missing, it is assumed to be 0 (zero).
120 14 Davide Pesavento
If this feature is enabled but FragCount is missing, it is assumed to be 1 (one).
121 1 Junxiao Shi
If this feature is disabled but either header field is received, the packet MUST be dropped.
122
123 14 Davide Pesavento
Unless otherwise specified, header fields from other features MUST appear only in the first fragment.
124 2 Alex Afanasyev
If a header field appears on a subsequent fragment, it MUST be ignored, unless otherwise specified.
125
126
## Network NACK
127
128
A network NACK is a forwarding instruction from upstream to downstream that indicates the upstream is unable to satisfy an Interest.
129
130
This feature defines a header field:
131
132 47 Junxiao Shi
    LpHeaderField =/ Nack
133 2 Alex Afanasyev
134 47 Junxiao Shi
    Nack = NACK-TYPE TLV-LENGTH [NackReason]
135 2 Alex Afanasyev
136 47 Junxiao Shi
    NackReason = NACK-REASON-TYPE TLV-LENGTH nonNegativeInteger
137 2 Alex Afanasyev
138
**Nack** header field indicates an Interest is a NACK, and is not a normal Interest.
139
The receiver MUST NOT process the packet as an Interest.
140
141
**NackReason** element MAY be included to indicate why the NACK is transmitted.  
142
The following NackReason values are defined:
143
144
Code  | Reason       | Description
145
----- | ------------ | --------------------------------------------------------------
146
0     | None         | (reserved)
147
50    | Congestion   | there is a congestion in the link between upstream and downstream, or on the best-known path between upstream and content source
148
100   | Duplicate    | the upstream has detected a duplicate Nonce in the Interest sent by the downstream
149
150   | NoRoute      | the upstream has no path to reach a content source due to routing problem or link failure
150
151
A receiver MUST be prepared to process a NACK without a reason.  
152
If NackReason element contains an unrecognized reason, the receiver MUST treat this NACK as a NACK without reason, and MUST NOT drop the packet.
153
154
Example of NACK of an Interest for `/example` with NACK reason "Duplicate":
155
156
    +--------------------------+---------------+
157
    | LpPacket                 | Interest      |
158 1 Junxiao Shi
    |                          | Name=/example |
159 2 Alex Afanasyev
    | +-Nack-----------------+ | Nonce=35      |
160 1 Junxiao Shi
    | | NackReason=Duplicate | |               |
161 2 Alex Afanasyev
    | +----------------------+ |               |
162
    +--------------------------+---------------+
163
164
It's RECOMMENDED to enable this feature on every link.  
165
If this feature is disabled but Nack is received, the packet MUST be dropped.
166
167
Nack header field is permitted only on an LpPacket carrying an Interest.  
168
When Nack appears on an LpPacket carrying a network layer packet other than an Interest, the packet MUST be dropped.
169 13 Davide Pesavento
170 2 Alex Afanasyev
## Consumer-Controlled Forwarding
171 13 Davide Pesavento
172 2 Alex Afanasyev
Consumer-controlled forwarding allows a local consumer application to explicitly specify the nexthop face to forward an Interest.
173
174
This feature defines a header field:
175
176 47 Junxiao Shi
    LpHeaderField =/ NextHopFaceId
177 2 Alex Afanasyev
178 47 Junxiao Shi
    NextHopFaceId = NEXT-HOP-FACE-ID-TYPE TLV-LENGTH nonNegativeInteger
179 1 Junxiao Shi
180 2 Alex Afanasyev
**NextHopFaceId** indicates the nexthop FaceId to which an Interest should be forwarded.
181 1 Junxiao Shi
A local consumer application MAY add this field to an LpPacket carrying an Interest.
182 2 Alex Afanasyev
The local forwarder SHOULD follow this instruction and forward the Interest to the specified nexthop, after ContentStore lookup does not find a match.
183 1 Junxiao Shi
184 2 Alex Afanasyev
This feature is designed to be used on local faces only.
185
It SHOULD NOT be enabled on non-local faces.
186
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.
187
If this feature is disabled but NextHopFaceId is received, the packet SHOULD be dropped, or this field MUST be ignored.
188
189 16 Junxiao Shi
NextHopFaceId header field is permitted only on an LpPacket carrying an Interest, from an application to the forwarder.
190 2 Alex Afanasyev
When NextHopFaceId appears on an LpPacket carrying a network layer packet other than an Interest, the packet MUST be dropped.
191
When NextHopFaceId appears on an LpPacket that has a Nack header field, the packet SHOULD be dropped.
192
When NextHopFaceId is received by an application from a forwarder, this field MUST be ignored.
193
194
## Local Cache Policy
195
196
Local cache policy feature allows a local producer application to instruct ContentStore on whether and how to cache a Data packet.
197
198
This feature defines a header field:
199
200 47 Junxiao Shi
    LpHeaderField =/ CachePolicy
201 2 Alex Afanasyev
202 47 Junxiao Shi
    CachePolicy = CACHE-POLICY-TYPE TLV-LENGTH CachePolicyType
203 2 Alex Afanasyev
204 47 Junxiao Shi
    CachePolicyType = CACHE-POLICY-TYPE-TYPE TLV-LENGTH nonNegativeInteger
205 2 Alex Afanasyev
206
**CachePolicy** header field gives a suggestion to the ContentStore.
207
The ContentStore MAY follow this suggestion.
208
209
**CachePolicyType** element MUST be included to indicate the suggestion.
210
The following CachePolicyType values are defined:
211
212
Code | Policy  | Description
213
-----|---------|--------------------------------
214
0    | None    | (reserved)
215
1    | NoCache | ContentStore SHOULD NOT admit the Data packet
216
217
If CachePolicyType field contains an unknown policy code, the forwarder SHOULD drop the packet.
218
219 1 Junxiao Shi
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.
220 2 Alex Afanasyev
221 1 Junxiao Shi
Example for a Data packet with "NoCache" policy:
222 2 Alex Afanasyev
223
    +-----------------------------+---------------+
224
    | LpPacket                    | Data          |
225
    |                             | Name=/example |
226
    | +-CachePolicy-------------+ | Content=xxxx  |
227
    | | CachePolicyType=NoCache | | Signature=xx  |
228
    | +-------------------------+ |               |
229
    +-----------------------------+---------------+
230
231
This feature is designed to be used on local faces only.
232
It SHOULD NOT be enabled on non-local faces.
233
If this feature is disabled but CachePolicy is received, this field MUST be ignored.
234
235
CachePolicy header field is permitted only on an LpPacket carrying a Data packet, from an application to the forwarder.
236
When CachePolicy header field appears on an LpPacket carrying a network layer packet other than a Data packet, the packet MUST be dropped.
237 1 Junxiao Shi
When CachePolicy is received by an application from a forwarder, this field MUST be ignored.
238 2 Alex Afanasyev
239 1 Junxiao Shi
## Incoming Face Indication
240 2 Alex Afanasyev
241
Incoming face indication feature allows the forwarder to inform local applications about the face on which a packet is received.
242
243
This feature defines a header field:
244
245 47 Junxiao Shi
    LpHeaderField =/ IncomingFaceId
246 2 Alex Afanasyev
247 47 Junxiao Shi
    IncomingFaceId = INCOMING-FACE-ID-TYPE TLV-LENGTH nonNegativeInteger
248 2 Alex Afanasyev
249
**IncomingFaceId** contains the FaceId from which the network layer packet is received.
250
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.
251
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.
252 1 Junxiao Shi
Even if this feature is enabled, the application MUST be prepared to receive a packet without IncomingFaceId field.
253 2 Alex Afanasyev
254 1 Junxiao Shi
This feature is designed to be used on local faces only.
255 2 Alex Afanasyev
It SHOULD NOT be enabled on non-local faces.
256 1 Junxiao Shi
257 2 Alex Afanasyev
IncomingFaceId header field is permitted only on an LpPacket from the forwarder to an application.
258
When IncomingFaceId is received by the forwarder from an application, this field MUST be ignored.
259
260 1 Junxiao Shi
## Congestion Marking
261
262 5 Eric Newberry
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.
263 1 Junxiao Shi
264
This features defines a header field:
265 5 Eric Newberry
266 47 Junxiao Shi
    LpHeaderField =/ CongestionMark
267 5 Eric Newberry
268 47 Junxiao Shi
    CongestionMark = CONGESTION-MARK-TYPE TLV-LENGTH nonNegativeInteger
269 1 Junxiao Shi
270 5 Eric Newberry
## Link Layer Reliability
271 9 Eric Newberry
272
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.
273 14 Davide Pesavento
274 9 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.
275 15 Eric Newberry
276 9 Eric Newberry
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.
277 14 Davide Pesavento
278 9 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. 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. An idle Ack timer is used to handle links that have gone idle. If a packet with a TxSequence is received and the packet has not been started, or has expired, the timer is started with a period of 5ms (or another configurable non-zero time period). Upon expiration of the timer, all Acks in the queue will be sent in IDLE packets.
279 11 Eric Newberry
280 9 Eric Newberry
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.
281 12 Eric Newberry
282
Multiple Ack fields can be sent in one LpPacket. If an Ack is received for an unknown TxSequence, the Ack will be ignored.
283
284 47 Junxiao Shi
    LpHeaderField =/ TxSequence / Ack
285 1 Junxiao Shi
286 47 Junxiao Shi
    TxSequence = TX-SEQUENCE-TYPE TLV-LENGTH 8OCTET
287 9 Eric Newberry
288 47 Junxiao Shi
    Ack = ACK-TYPE TLV-LENGTH 8OCTET
289 1 Junxiao Shi
290 9 Eric Newberry
**Modified from "Hop-By-Hop Best Effort Link Layer Reliability in Named Data Networking" by S. Vusirikala, et al.**
291 45 Davide Pesavento
292 1 Junxiao Shi
## Self-Learning Forwarding Support
293 23 Junxiao Shi
294 1 Junxiao Shi
[NDN self-learning](https://named-data.net/publications/on_broadcast-based_self-learning_ndn/) is a forwarding protocol that can automatically discover contents and forwarding paths in local area networks. This feature adds two hop-by-hop headers to support this forwarding protocol.
295 23 Junxiao Shi
296 47 Junxiao Shi
    LpHeaderField =/ NonDiscovery / PrefixAnnouncement
297 23 Junxiao Shi
298 47 Junxiao Shi
    NonDiscovery = NON-DISCOVERY-TYPE
299
                   TLV-LENGTH ; == 0
300 23 Junxiao Shi
301 47 Junxiao Shi
    PrefixAnnouncement =/ PREFIX-ANNOUNCEMENT-TYPE TLV-LENGTH Data
302 28 Teng Liang
303 23 Junxiao Shi
Self-learning distinguishes an Interest as either "discovery" or "non-discovery". A node transmits a discovery Interest to explore new forwarding paths, or transmits a non-discovery Interest to exploit existing forwarding paths. The **NonDiscovery** field indicates an Interest is "non-discovery"; otherwise, an Interest without this field is "discovery".
304
This field can only appear on an Interest. If this field appears on a Data or a Nack, the LpPacket MUST be dropped. If the self-learning forwarding protocol support feature is disabled or the chosen forwarding strategy does not support self-learning, this field SHOULD be ignored.
305
306 43 Teng Liang
When replying to a discovery Interest, the upstream node SHOULD transmit the Data with a **PrefixAnnouncementHeader** field. This field indicates what name prefix the producer is serving, and assists the downstream node in updating its FIB. A PrefixAnnouncement contains a single Data TLV element, and the Data format follows the [[PrefixAnnouncement]] Protocol.
307 42 Davide Pesavento
308 43 Teng Liang
 
309 41 Teng Liang
This field can only appear on a Data. If this field appears on an Interest or a Nack, the LpPacket MUST be dropped. If the self-learning forwarding protocol support feature is disabled or the chosen forwarding strategy does not support self-learning, this field SHOULD be ignored.
310 22 Teng Liang
311 16 Junxiao Shi
## TLV-TYPE Number Assignments
312 2 Alex Afanasyev
313 26 Davide Pesavento
type                     | number (dec)     | number (hex)
314
-------------------------|------------------|------------------
315 25 Junxiao Shi
Fragment                 | 80               | 0x50
316
Sequence                 | 81               | 0x51
317 1 Junxiao Shi
FragIndex                | 82               | 0x52
318
FragCount                | 83               | 0x53
319 25 Junxiao Shi
HopCount (ndnSIM)        | 84               | 0x54
320 26 Davide Pesavento
PitToken (NIST, #4432)   | 98               | 0x62
321
LpPacket                 | 100              | 0x64
322 25 Junxiao Shi
Nack                     | 800              | 0x0320
323
NackReason               | 801              | 0x0321
324
NextHopFaceId            | 816              | 0x0330
325
IncomingFaceId           | 817              | 0x0331
326
CachePolicy              | 820              | 0x0334
327
CachePolicyType          | 821              | 0x0335
328
CongestionMark           | 832              | 0x0340
329
Ack                      | 836              | 0x0344
330
TxSequence               | 840              | 0x0348
331 20 Davide Pesavento
NonDiscovery             | 844              | 0x034C
332 2 Alex Afanasyev
PrefixAnnouncement       | 848              | 0x0350
333 1 Junxiao Shi
334 2 Alex Afanasyev
### Reserved Blocks
335
336 45 Davide Pesavento
Two blocks of TLV-TYPEs have been reserved by link protocols:
337 2 Alex Afanasyev
338 27 Davide Pesavento
* `[80, 100]`: 1-octet encoding
339
* `[800, 1000]`: 3-octet encoding
340 2 Alex Afanasyev
341 16 Junxiao Shi
TLV-TYPE numbers for LpHeaderField SHOULD be assigned according to the following rules:
342 2 Alex Afanasyev
343 27 Davide Pesavento
1. if the field can be safely ignored by a receiver that doesn't understand the field, pick an unused number in the range `[800, 959]` whose two least significant bits are `00`.
344
2. if the field would occur frequently, pick an unused number in the range `[81, 99]`.
345
3. otherwise, pick an unused number in the range `[800, 959]` whose two least significant bits are `01`.
346 2 Alex Afanasyev
347 16 Junxiao Shi
Note: number assignment for a TLV-TYPE nested within a LpHeaderField is not restricted by the above rules.