Feature #3104
closed
NDNLPv2: GenericLinkService encoding/decoding
Added by Junxiao Shi over 9 years ago.
Updated about 9 years ago.
Description
Develop GenericLinkService to support NDNLPv2 hop-by-hop headers.
GenericLinkService shall conform to the GenericLinkService external API given in LinkService-face.hpp.
In this issue, GenericLinkService should encode and decode LpPacket with these fields:
- NACK
- extra fields for forwarding: NextHopFaceId, CachePolicy, IncomingFaceId
No other NDNLPv2 features should be supported at this moment.
- Assignee set to Eric Newberry
The design needs to be reviewed before starting implementation.
The initial design reviews will be conducted internally at Arizona.
Hints for design:
The design needs to answer the following questions:
- What's the send path and receive path?
With only the features listed in issue description, it would be simpler than LinkService_20150828.pptx.
- How to process fragmentation and reassembly when
GenericLinkService is working with a multi-access underlying link?
Hint: reassemble packets from each source address separately
- Show the public API for classes used in fragmentation and reassembly (as a header).
- Show the full API for
GenericLinkService (as a header).
- Blocked by Task #3088: Refactor Face as LinkService+Transport added
- Related to Feature #3171: NDNLPv2 fragmentation and reassembly added
- Estimated time changed from 24.00 h to 12.00 h
Implementation of fragmentation and reassembly building blocks is split into #3171 so that it's individually assignable.
The boundary of fragmentation and reassembly building blocks is:
- Given an unfragmented packet, MTU, and an estimated header size (for NACK, etc), the fragmentation building block can slice the packet into multiple LpPackets.
This is similar to nfd::ndnlp::Slicer in NDNLPv1 implementation, except that sequence numbers are not assigned.
- Given received packets from a single source, the reassembly building block can reassemble packets.
This is similar to nfd::ndnlp::PartialMessageStore in NDNLPv1 implementation.
#3104 should decide the exact API to be provided by #3171.
When working with a multi-access transport, #3104 should find a way to arrange multiple reassembler instances, one for each remote sender.
As mentioned in #3178 note-1, part of this issue should have higher priority:
Enhance packet encoding/decoding procedures from #3088, to have not only Nack, but also LocalControlHeader-equivalent fields.
This includes full unit testing for encoding/decoding.
After this is done, we can continue onto the design of whole GenericLinkService and the implementation of fragmentation.
- Description updated (diff)
"higher priority" part described in note-6 is not blocked by #3179, and can start as soon as #3088 is complete.
Documentation requirement is moved to #3173.
- Related to deleted (Feature #3171: NDNLPv2 fragmentation and reassembly)
- Subject changed from NDNLPv2: GenericLinkService to NDNLPv2: GenericLinkService encoding/decoding
- Description updated (diff)
- Estimated time changed from 12.00 h to 3.00 h
I'm updating this issue to include only packet encoding/decoding.
Fragmentation and reassembly are split to #3171.
- Status changed from New to In Progress
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
- Status changed from Code review to Closed
Also available in: Atom
PDF
Updated by 
Updated by