1. Pages
2. …
3. Open Transport Configuration and Control Home
4. 5G-xHaul
5. 5G-xHaul Call-in Details & Notes

2020-04-01 5G-xHaul Meeting notes

Update by Lumina:

• New ODL implementation is according RFC8040
• mapping int32 - int64 - string

https://tools.ietf.org/html/rfc7951 → chapter 6.1

[...]
A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950].
[...]

The reason comes from the JavaScript specification:

https://developers.google.com/discovery/v1/type-format

[...]

For example, a 64-bit integer cannot be represented in JSON (since JavaScript and JSON support integers up to 2^53). Therefore, a 64-bit integer must be represented as a string in JSON requests/responses. So the type property will be set to "string", but the format property will be set to "int64" to indicate that it is a 64-bit integer.

[...]

PM counters needs int64.
Application developer issue → no issue in xml, App developer must know how to RestConf using json and xml.

Proposal:

Models will not change - int64 is required. 

Decision:

Models will not change - int64 is required. 

@Pawel Krecicki

ODU presentation

• two representations

• top level vs actual equipment

No decisions and discussions were made for connector in the past. 

How should be ODU models - options

ODU is a separated box → top level equipment . independent equipment with no dependency to IDU

ODU is managed by IDU → actual equipment

Proposal (under development):

ODU presentation as SFP → actual equipment ("virtual" slot → holder with ODU as equipment) 

IF port → holder vs connector

RF port is sitting on ODU

AI: Questions to the vendors

What are the advantages and drawbacks of the ODU presentation in a SFP like way?

Instantiation procedure like wire-equipment?

Decision:

summer: 2am ONF time → 11:00 CEST → 12:00 Israel summer time   → 17:00 China

winter: 2am ONF time → 11:00 CET → 12:00 Israel standard time   → 18:00 China

Next Meeting: 

2020-04-08: 2am ONF time → 11:00 CEST → 12:00 Israel summer time   → 17:00 China

AI Martin: update meeting invitation

0min

core-model allows definition of both Logical Termination Points (interfaces), but also connections

• Forwarding Domain:
  • either connections inside the same device
  • connections outside devices
• Link:
  • any type of link, not only microwave
• Forwarding Construct:
  • concrete forwarding between two or more LTPs / ports
    • unidirectional / bidirectional

core-model is also suitable for representing entire Networks, not only a Device

this means that Universally Unique IDs are required

Devices cannot get the UUIDs from outside, they need to be generated by the device, and cannot be overwritten from outside

Devices are unaware by their surroundings (the network), so it cannot know if a UUID is already used by some other interface in other devices

IETF defines how to create UUIDs, and the core-model references this RFC

• we need UUIDs for documenting the network
• we cannot write the UUIDs in the device, the device needs to create it 
• the device does not have a network wide view
• this is needed because of the Planning the network

Possible solutions:

• the device generates whatever, the IDs are retrieved and a mapping table is maintained
• we prescribe a method/algorithm that is implemented in the device for creating UUIDs (which become predictable):
  • using some prefix which is known during the implementation time of the device - (e.g. MAC address of the Management interface); vendor sends info about Order no. and MAC addr. to the operator and the Planning will be done with these prefixed values → less complex than a field technician configuring the prefix on the device with some dongle
  • fixed UUID with prefix and postfix

Suggestions:

• use the Device name instead of the MAC addr.
• clean-up application that handles the changing of MAC addresses

Out of time, we need to follow up: proposal, next week Tuesday 09:00 CET