TI API: Rel 0.9.5

[FabrizioMoggio]

What type of PR is this?

• enhancement/feature

What this PR does / why we need it:

This PR:

• Updates the documentation to better specify how to identify a Device
• Updates the Device parameter according to CAMARA_common.yaml: Usage of IP Address to identify a Device in Traffic Influence API #123
• Changes the API name in YAML according to: Rename traffic Influence in .yaml file line 7 #243
• introduces sourceTrafficFilters and modifies trafficFilters into destinationTrafficFilters according to: TI API - New potential requirement: Device Source IP Port #230

Which issue(s) this PR fixes:

#123
#243

[FabrizioMoggio]

In my understanding, according to: https://wiki.camaraproject.org/display/CAM/API+versioning, the TI API should already be an Alpha release. Anyway, to keep it simple, I suggest to have the formal step to approve this PR and to make a new one with just the release modification from WIP to Alpha. Unless we consider having the API as WIP as a bug, considering it already has a public release: V0.8.1. In this case I can fix the release numbering immediately in this very PR.

---update (I don't delete to keep track): In my understanding the process is the following:

• First development phase of a new release: WIP
• New release consolidated, some improvement ongoing: Alpha
• Development completed, testing ongoing: -RC

Because we are going to introduce new features (e.g. #218) we can still be WIP.

[nicolacdnll]

I saw that some other parts could get this as well.
Something like sed 's/\([A-Za-z0-9]\)\*\*/\1\:\*\*/g should do the trick.

[FabrizioMoggio]

right, fixed

[gunjald]

I think we need to differentiate qualify between "application" in sourceTrafficFilters and one in destinationTrafficFilters description. While the application in sourceTrafficFilters seems to refer to device the destinationTrafficFilters could be referring to EAS. This is to avoid any confusion w.r.t terms we have defined so far

[FabrizioMoggio]

we have:

source private ip and port
source public ip and port
destination ip, port and protocol

in sourceTrafficFilter we have the source private port.

according to: #230 (reply in thread)

we need to better specify this.

[FabrizioMoggio]

I'm wondering @babunkj how the UPF can be effected by the "source private ip"

[babunkj]

I'm wondering @babunkj how the UPF can be effected by the "source private ip"

The packet Detection Rules in the UPF can include the source device Ip address and port and the destination IP Address and port.

[babunkj]

We can use 'specific source port in the Device' or 'specific application client port in the Device' instead of 'specific application port in the Device'.

[FabrizioMoggio]

@babunkj sure, we will not use APPLICATION port in the description

Anyway, it is totally clear to me that the "source port" is required, my doubt is about "source PRIVATE port". The UPF is indeed effected by the "source PUBLIC port". The all discussion here is around:

1. agreement on having the "source PUBLIC port"
2. discussion on also having the "source PRIVATE port"

I'm still not sure, even after this: #249 (comment) if you are asking for the PUBLIC or PRIVATE or both :-). Sorry it is totally my fault not being an expert in this field.

[babunkj]

@FabrizioMoggio the UPF looks at source PRIVATE Port since the translation from PRIVATE to PUBLIC happens after UPF processing (in Uplink direction which is what we are concerned with for Traffic Influence).

Regarding what ports to include in the request, my comment is that both are required:
PUBLIC port is required to identify the device. It can be part of the Device identifier attribute.
PRIVATE port is required to identify the traffic. This can be part of sourceTrafficFilter attribute.

[FabrizioMoggio]

dear @babunkj thank you so much, that is correct, in a traditional scenario, you are totally right. Now I got you.

My confusion is due to the discussion we are having in FWA (or tethering), that is what @gunjald was referring to, according to my understanding. In FWA we have a device with a "Private-1 IP/Port" connected to a FWA device. The FWA device translate it to "Private-2 IP/Port". This is what the UPF gets. Than we have CGAT and so "Public IP/Port"

Private-1 (in the LAN)
Private-2 (Core Network)
Public (Internet)

I was focusing on Private-1 forgetting about Private-2 :-).

So we currently we have:

Device: with Private-1-IP and and Public-IP and Public-Port

Where Private-1=Private-2 for a smartphone. In this scenario, the common one, we need to introduce, I agree with you, Private-1-Port. Because this is the Port the UPF uses.

This is not enough for FWA or tethering. In this scenario Private-1 is different from Private-2 and we also need Private-2-IP and Private-2-Port. In this scenario indeed the UPF works with Private-2-IP and Private-2-Port.

About Private-1-IP: it is provided by the client to the API Consumer that puts it into Device
About Public-IP: it is discovered by the API Consumer that puts it into Device
About Private-2-IP: it can be discovered by the Network, knowing Public-IP

What about Private-2-Port? how can we get it?

[babunkj]

Right @FabrizioMoggio. That is an interesting scenario for FWA and mobile devices which act as hotspot.
I think the Private-2-IP and Private-2-Port you referred to may be derived from the Public IP and Public Port (Reverse mapping in NAT). However, these values are not visible to the Application server.

[gunjald]

Shouldnt it have destinationProtocol too in sourceTrafficFilters?

[FabrizioMoggio]

I don't think so. the Protocol for the flow is the one defined in destinationTrafficFilter. It should be the same also for the source

[gunjald]

I agree. So then should we separate out port so that it is explicitly mentioned as a distinct field which associate with both source and destination filters commonly?

[FabrizioMoggio]

We could have:

sourceTrafficPort
destinationTrafficPort
trafficProtocol

and we remove trafficFilters

[gunjald]

The only thing i feel is that if we should include the source or destination IP address or not? If we want to keep IP addresses then trafficFilters still seems fine. If we dont include IP addresses then the above proposal looks fine.

If we chose to keep IP addresses then it could be in similar lines sourceTrafficFilter, destinationTrafficfilter, trafficProtocol?

[FabrizioMoggio]

not sure to get the comment :-)

we already have:

• device: with the source IP (public and private) and public Port

I'm proposing to add:

• sourceTrafficPort: the source private Port
• destinationTrafficPort: the destinatin public port
• trafficProtocol: the protocol, that is the same for source and destination

removing the trafficFilters

[gunjald]

With minor change I agree with this,

• Device refers to Source and Destination refers to EAS
• device: represented by the source public IP and public Port (we may not need to use private IP in my opinion)
• sourceTrafficPort: the source (device) public Port
• destinationTrafficPort: the destination public port
• trafficProtocol: the protocol, that is the same for source and destination

Please note that everything is expressed as public from external applications perspective.

[FabrizioMoggio]

my understanding was that we had to also provide information about the device PRIVATE port. The source public port is already in Device.

this according to @babunkj , in this comment: #230 (reply in thread)

[gunjald]

we need then more information from @babunkj As in my opinion externally only the public IP and port are visible. Unless it is explicitly specified that the applications hosted in telco edge cloud zone can see both private and public IP:Port.

In general we do not have any visibility how the EAS will see the IP port in device traffic when hosted in edge cloud zone and if different operator will have different model to expose private or public IP of the device it will be difficult to say which one the EAS will see in which deployment. I think we need more feedback from the operator on the possibilities and how well we can address them.

[babunkj]

Let me first try to (re)state the requirement before giving the comments:
a) The scenario is: A device has more than one traffic originating from it with the same source IP Address and different ports, but only a specific traffic (identified by a specific port) needs to be influenced and diverted to say an Edge cloud. This requirement needs the identification of the source traffic by its source IP Address and source port.
An example use case is: when an always-on low resolution video traffic from a device is analysed and a trigger is detected, switch the high resolution video traffic alone to the edge cloud.

b) In an extended case of the above one: based on traffic from say Port A, the traffic from a set of ports or all Ports are to be influenced and diverted to an Edge cloud.
An example use case is: when an always-on low resolution video traffic from a device is analysed and a trigger is detected, switch all high resolution video traffic or all video traffic from that device to the edge cloud.

The solution to the above becomes a challenge due to NATing. Giving my comments for IPv4 and IPv6 cases:

IPv4:

• In the case of IPv4, even though the combination of External IP and External Port will identify the device uniquely, the source port is also required in order to identify the traffic. However, only External IP and External Port are directly visible externally in the case of IPv4.
• Since it wouldn’t be possible to derive source port directly from the IP headers by the application server, suggesting the following:

a) If NAT element supports sharing of IP Address-Port mapping, the source port can be fetched by the operator platform (not available to application server)
b) When the source port(s) is known to the application server (indirectly), use that info in the source traffic filter.
c) When the source port is omitted, the traffic influence is to be applied to all traffic for the session from the device (as provided in the current version)

IPv6:
For IPv6, I suppose, the device port (source port) could be visible to the external server and can be used in the source traffic filter. Not sure how operator networks handle NAT for IPv6.

Another comment is that I feel it is better to keep the sourceTrafficFilters and destinationTrafficFilters attributes as defined in the version 0.9.5-wip. They indicate the purpose. The current structure is also more amenable for future enhancements.

We could discuss this over a call if that helps.

[gunjald]

In general the port and IP address are used together for identification of specific traffic flow. Is there a need to include the IP address of device or EAS in source and destination traffic filters?

[FabrizioMoggio]

the IP address for the source is already in Device. For the destination, we are currently just targeting application deplyed by the OP so, the destination IP is already known by the Transformation function as a consequence of AppId or AppInstanceId.

We are discussing in OPAG about this: "Support for External EAS". If we move forward with that requirement, the destination IP is required

[gunjald]

I think the observation is partly correct but then i see another point that if the application has multiple components then how would AppId or AppInstanceId.can be used to determine the right component if the components are having different IPs? Any suggestion or thought in such scenario?

[FabrizioMoggio]

do you mean an Application that is exposing different IPs, Ports and maybe protocols, and the Service Provider wants to influence just some of them? Currently this is not supported. Anyway this can be a step toward the support for external EAS. even more, if we implement this, we also have the support for external EAS for free :-)

[gunjald]

I think we should document this part about the IP model used as it may lead to confusions. We need to ensure that an application is currently be accessible via a single IP only and may have different port associated to that IP. As this part is not explicit anywhere an app with multi component can have such traits that different components are accessible over different IPs then there could be issues.

So in my opinion we should need to capture this part explicitly but then in App LCM APIs we would need to discuss that this assumption is valid and will work correctly with TI API.

[FabrizioMoggio]

sure, if you open a discussion in App LCM, can you please link it here?

[gunjald]

Sure I will open a discussion in App LCM and link it here.

[gunjald]

Following discussion has been opened, #264

[FabrizioMoggio]

Conclusion, considering:

#249 (comment)

and:

#249 (comment)

A device can have:

Private-1 IP and Port (in the LAN)
Private-2 IP and Port (Core Network)
Public IP and Port (Internet)

UPF must be configured with Private-2 IP and Port.

The API Consumer is aware of "Private-1" and "Public"

"Private 1" = "Private 2" if the Device is a Smartphone directly connected to the network (no FWA or tethering).

In Device we have "Public IP and Port" that the API Consumer chooses according to the Flow of interest from the device. From this the OP can identify Private-2 IP and Port. If the API Consumer decides to use "Public IP and Port" as identifier we are ok.

If the API Consumer chooses phoneNumber or networkAccessIdentifier we need sourceTrafficFilter to define Private-2 Port. The Problem is that Private-2 Port is not known by the API Consumer. So it can not fill it.

To cover FWA and tethering we should not use Device, with the many options, but we need to identify the UE just with "Public IP and Port".

Proposal:

• limit Device to just "Public IP" and phoneNumber (I can get the Public IP from it)
• adding a list Public Ports.

[babunkj]

@FabrizioMoggio, one query on the above comment. We can limit the device identifier to just "Public IP and Port".
But for the Application server to indicate if the influence is to be done on one port or many ports, the sourceTrafficFilters may be there in which the 'specific source port' or 'all source ports' can be differentiated.

[FabrizioMoggio]

@FabrizioMoggio, one query on the above comment. We can limit the device identifier to just "Public IP and Port". But for the Application server to indicate if the influence is to be done on one port or many ports, the sourceTrafficFilters may be there in which the 'specific source port' or 'all source ports' can be differentiated.

I see, we can't use Device as defined by Commonalities. We need to define our own source identifier parameter. We can name it: SourceDevice. I see two options:

1. SourceDevice that also includes list of ports. We don't need sourceTrafficFilter

SourceDevice:

• Public IP
• Phone Number
• list of Public Ports

2. SourceDevice without the list of ports. We need sourceTrafficFilter

SourceDevice:

• Public IP
• Phone Number

sourceTrafficFilters:

• list of Public Ports

[babunkj]

I think option 2 with some small changes will be clearer to the user since it demarcates the Device and Traffic attributes.
I feel we can still keep the device format as it is. The name sourceDevice may confuse the user.
Device:
• Public IP and Public Port
• Phone Number
(Public port becomes optional for IPv6)
sourceTrafficFilters:
• list of Ports.
(the list of ports can be applicable to IPv4 and Ipv6)

[FabrizioMoggio]

@babunkj I see you point . My concern on adopting a parameter named Device is that it can be confusing for a Developer working in CAMARA to have a parameter named Device like the one in Commonalities but different.

To everyone: Any idea for a better name, like InfluencedDevice or TI_Device or do we stick to Device with an high level note in the documentation explaining why it is different from the one in Commonalities ?

[gunjald]

ist of Ports.

I think the API should be aligned with other APIs for common aspects where the commonality group guidelines can be followed and two different terms should be avoided for the same concept.

So if all the other APIs refers to the term "Device" then we should also follow that while traffic patters can be something which we may define like sourceTrafficFilter or destTrafficFilter etc

[FabrizioMoggio]

@gunjald as a principle, I agree with you but here it doesn't work unless we decide that, to add more ports, the API Consumer invokes the TI API more times, as if they were different users. This is because "Commonalities-Device" already has sourcePort included, just one though. An alternative to avoid the API Consumer calling the TI API many times for the same user, is to use sourceTrafficFilters to add more ports. We should explain this very well in the documentation.

Another problem with "Commonalities-Device", is that it also includes PrivateIP that doesn't always work for the TI API (FWA or Tethering). We should anyway have a TI_Device that is derived from Commonalities-Device with the PrivateIP blocked somehow.

[gunjald]

@FabrizioMoggio as I understand there are two issues. First one is the device identification which may itself contain an IP, public or private as you said, and then the second one is the traffic identification.

For the device identification i thin any combination of its public IP or the private IP along with associated ports should be able to determine the same device and as you suggested it could be TI_Device or something like that but this should be used only for device identification and not for the traffic identification.
For the traffic identification the sourceTrafficFilters or destTrafficFilters can be defined with the option of specifying multiple ports to avoid multiple TI API invocation.

Are you thinking something similar?

[FabrizioMoggio]

Yes I am, I have checked Commonalities-Device. it uses DeviceIpv4Addr:

that has
anyOf:
- required: [publicAddress, privateAddress]
- required: [publicAddress, publicPort]

So PublicIP is anyway mandatory.

Proposal:

• we use Device as defined in Commonalities
• we add sourceTrafficFilters to provide the option to add more PublicPorts
• we add a good explanation in the Documentation :-)

[gunjald]

I agree to your proposal. Just one thing. Should we keep destTrafficFilters as well for cases where EAS IP and port information is available for a given device and developer may want to use that?

[FabrizioMoggio]

yes, we also keep destTrafficFilters

[gunjald]

I am all good with the proposal :-)

[FabrizioMoggio]

@babunkj is this ok with you?

[babunkj]

Yes @FabrizioMoggio . Your proposal to use Device attribute as defined in Commonalities, add sourceTrafficFilters to provide the option to add more ports (let us call it sourcePorts as you had defined now) and give a good explanation in the Documentation is fine.