TI API - New potential requirement: Device Source IP Port #230
Replies: 14 comments 55 replies
-
|
I will add this topic to the agenda to ask for feedback, @FabrizioMoggio if you can explain there a bit what this new requirement is about it would be perfect. |
Beta Was this translation helpful? Give feedback.
-
|
There are scenarios where a device has multiple traffic/streams which are identified based on Port numbers. An example is the camera with low and high resolution traffic which have different port numbers allocated to each. There are use cases where only one or selected streams from the device need to be routed to a specific Edge or Application Server. This identification of the traffic can be done by introducing source port numbers in the request, wherein which the Application can specify which stream (corresponding to the ports mentioned) need to be routed / influenced. |
Beta Was this translation helpful? Give feedback.
-
|
I think in current version the device is represented by its IPV4 address and the array of port and protocol associated it with which i will assume as the port of the edge application server based on my interpretation of the trafficFilters description. So even though the traffic can be filtered but i will assume that the filtered traffic will be routed to the edge application identified by appId but the API doesnt support routing a specific traffic flow to different applications or EAS in my opinion. |
Beta Was this translation helpful? Give feedback.
-
|
@gunjald that is correct. Actually Port Number is only for the Destination (the EAS) and not for the Source (the Device). This is way I was proposing this new requirement to add the support for Device Source IP Port. A possible use case is actually provided by you in this discussion: Am I wrong? |
Beta Was this translation helpful? Give feedback.
-
|
I think for the sake of clarity we need to define the terms The Device, Destination, Source, Port etc. It becomes difficult to model which terms mean what at times. For example when we say Source IP does it mean device IP? When we say port where do we relate it to i.e. to Device or to EAS? Also, my suggestion would be to refer to source IP, source Port, and destination IP , destination port just to ensure they are being taken up together and can form a unique key. |
Beta Was this translation helpful? Give feedback.
-
|
Currently we have in the TrafficInfluence resource some attibutes related to the Destination EAS and some others related to the Source that is the smartphone: -Device: here we identify the Source With the goal to manage a Source port, we can modify Device adding a new "devicePort" parameter, maybe in Ipv4Address and Ipv6Address definition. or even better we can define two trafficFilters: destintionTrafficFilters and sourceTrafficFilters. So we don't need to modifiy Device or Ipv4Address and Ipv6Address. I propose to introduce: destintionTrafficFilters and sourceTrafficFilters |
Beta Was this translation helpful? Give feedback.
-
|
I'm wondering:
|
Beta Was this translation helpful? Give feedback.
-
|
I think introduction of destintionTrafficFilters and sourceTrafficFilters will help as it clearly segregate the source and destination entities. But we will also need to explain the relationship between the set of IP addresses used in device->ipv4Address/ipv6Address parameters and the ones to be used in sourceTrafficFilters if we define so. And the possible addresses, their nature and how the application developers can obtain it specially the private addresses if they are also valid for the API. I think we need more discussion within the group as suggested by @babunkj |
Beta Was this translation helpful? Give feedback.
-
|
@gunjald do you suggest to discuss this in the Edge Cloud regular meeting or to set up a TI API specific call? Is this topic of interest for the whole group? |
Beta Was this translation helpful? Give feedback.
-
|
One more comment, for the TI API, the invoker is usually the App Backend that is aware of the public IP for the Device so, for this API we shouldn't have any problem. Anyway this must be well described in the documentation. I don't see the TI API ever using private IP and ports for the Device, only the public ones are used. |
Beta Was this translation helpful? Give feedback.
-
|
One point on IP, port mapping for specific flows in my opinion is that determining the mapping between internal IP:Port with the NATed IP:Port may be a bit of work as the mapping at NAT gateway will be performed dynamically. So if we can provide some references to help promote the understanding of parameters nature and how reliably they can be determined will really help speedy development. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, introducing destintionTrafficFilters and sourceTrafficFilters will bring more clarity on how the application can define 'what to influence'. They can be such that application can create them with minimum information that it may have. |
Beta Was this translation helpful? Give feedback.
-
|
About the improvement in the Documentation that is needed, we can start looking at: Commonalities have this document on UE identification: https://github.com/camaraproject/Commonalities/blob/main/documentation/UE-Identification.md#af-specific-ue-external-identifier |
Beta Was this translation helpful? Give feedback.
-
|
@babunkj you are right. That was not clear to me until now:
So: we adopt the new Device definition from CAMARA_common.yaml, we introduce sourceTrafficFilters and we rename the old one into destinationTrafficFilters Please note the on Device there is still an ongoing discussion: camaraproject/Commonalities#171 |
Beta Was this translation helpful? Give feedback.
-
|
I have a question to ask on "public IP port: to identify the device under NAT". As per my understanding a device will have a private IP address assigned by mobile core to it. But the port in "Public IP:Port" is something which will be specific to a traffic flow going out from the mobile network to external applications and that too will be associated to a specific protocol e.g. TCP, UDP. So how do we explain the meaning of port in "public IP port": to application developer as it is a dynamic port which can keep changing as the NAT gateway performs the mapping of internal port with private IP dynamically with a possibly different public port at different time and based on events like idle timeouts, location change resulting into dataplane change etc. From application provider perspective he should be given network agnostic view in terms of what all scenario he should observe and what all action the application may need to take on those events e.g. determining IP:Port mapping changed and earlier mapping becomes invalid. So how developer can detect such events and initiate the API calls again. But these are just my thoughts and would like to understand if the given concepts or parameter usage needs to viewed differently? |
Beta Was this translation helpful? Give feedback.
-
|
I'm wondering if it is not better, for the Developer, just to give us the Phone Number and from that, the OP can identify the private IP assigned to that phone number by the UPF. this is actually what we need to configure the routing rules on the UPF, isn't it @babunkj. It works for a Smartphone. I think that a device attached to a Fix Network router is out of scope. A device attached to a 5G Router is tricky. Anyway we could clarify that this API works for Smartphones moving around. It is better to have a simple and clear solution for the most common use case than to support any kind of device proving a solution that is difficult to understand for the Developer. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Clearly having just phone number as an input forces the Service Provider to gather it and it is not always a request the Service Provider wants to do to the Customer. |
Beta Was this translation helpful? Give feedback.
-
|
Giving some views on the above comments of @FabrizioMoggio and @gunjald. As suggested by @FabrizioMoggio , I also think that for basic and simple cases using Phone number may be easier. A phone number is also the most often used identifier of a device. OP will be able to identify the private IP based on the phone number. |
Beta Was this translation helpful? Give feedback.
-
|
Additional information: GSMA OPG.03 defines Public_IP and Source Port to identify the UE. So we can at least have the following conclusion: Conclusion: We need to introduce Source IP port in the TI API How to, this is still under discussion but I suggest to be aligned with: #247 |
Beta Was this translation helpful? Give feedback.
-
|
Yes Fabrizio, it is aligned with your previous comment. May be the terminology we can keep same as used in QoD for "Device" object and which exist even for TI and can be modified with introduction of publicPort. as in QoD "ipv4Address": { "publicAddress": "203.0.113.0", "publicPort": 59765.} While you can enhance the traffic filters with your proposal on "destintionTrafficFilters and "sourceTrafficFilters:. Does it look aligns with your understanding? |
Beta Was this translation helpful? Give feedback.
-
|
Totally, I have already implemented this in 0.9.5 (not yet published), I still have one doubt before making the PR. I would like to better define the two Ports we have for the UE. The first port is the one in the Device parameter, publicPort. The second one is the port we have in sourceTrafficFilters. Currently I have this text: sourceTrafficFilters: The traffic can be from a specific application port in the Device. And in Device explanation text, I have: The Device can be identified by the phone number (phoneNumber), an external identifier (networkAccessIdentifier) or by its IP Address (Ipv4Address, Ipv6Address) also specifying a Port. So I named the first one "application port" and I can't find the right name for the second one (the one in the Device), Maybe "nat port"? |
Beta Was this translation helpful? Give feedback.
-
|
I think "So I named the first one "application port" and I can't find the right name for the second one (the one in the Device), Maybe "nat port"?" we can just use the publicPort same as the QoD as the device can have multiple traffic stream and there can be multiple NATed ports too. But the public Ip and public Port for different stream will still resolve to same device. As these ports are still under the "Device" object so implicitly they refer to device and we may not need to use terms like application port or nat port in my opinion. |
Beta Was this translation helpful? Give feedback.
-
|
maybe I'm lost...let me correct I'm lost for sure :-). a device can have a Private IP, a Public IP and a Public Port (Port 1) from an application point of view, it can originate traffic from a different Port (Port 2). Is this right? |
Beta Was this translation helpful? Give feedback.
-
|
May be it is about too many terms creating confusion. Let me try to put my understanding here. Device may have an internal IP within internal network dedicated to it. While reaching out to external applications over internet it originates IP packets with source IP as private IP and the internal source port towards the external Public IP and Port of EAS. This packet is translated by the CGNAT which assign a Public IP and Public Port managed by CGNAT for the Device Private IP and Private Port i.e. source IP and source Port in this conversation. I.e. Device Private IP and Private Port => Public IP, Public Port.(CGNAT). Please note that the above explanation is totally for device IP and port and nothing has been said about EAS which is assumed to be addressed in the destination IP and Destination Port in the IP packet. Now based on the different stream of traffic towards EAS the device may have source private IP and private port going via CGNAT and for each unique private, private port for the device CGNAT will allocate unique Public IP, Public Port . In that case using Public IP, Public Port of the device the private IP and Private Port mapping can be retrieved at CGNAT. Also, the EAS will see the Device Public Ip and Public Port in the IP packets it receives and may not have visibility of the Private IP and Private port within the internal mobile network. Hence we are proposing to use the Device Public IP and Public Port (could be one or more at same time for different traffic flows) to identify the device. I hope it aligns with your view. |
Beta Was this translation helpful? Give feedback.
-
|
According to the explanation ( thank you, I had it wrong before) I don't think we need sourceTrafficFilter. this is way I wasn't able to differentiate them, they are the same. Am I right? @babunkj what do you think? |
Beta Was this translation helpful? Give feedback.
-
|
ok, so currently I have this text: sourceTrafficFilters: The traffic can be from a specific application port in the Device. The Device can be identified by the phone number (phoneNumber), an external identifier (networkAccessIdentifier) or by its IP Address (Ipv4Address, Ipv6Address) also specifying a Port. Is this ok or do you suggest a better wording, naming? |
Beta Was this translation helpful? Give feedback.
-
|
Agree, in Traffic Influence, we need the device identifier to identify the device and an application flow identifier to identify the specific flow(s) to be influenced. This is similar to the QoD API. I think we can keep these two sets of attributes that an application user can easily identify with. Device Identifier attribute: Application flow attribute:
|
Beta Was this translation helpful? Give feedback.
-
|
I agree on aligning with QoD, thank you @babunkj |
Beta Was this translation helpful? Give feedback.
-
|
I'm wondering, @babunkj, you wrote Port(s). In QoD they actually define multiple ports. Currently for the destination Port we have just one port. Do we need to have multiple ports as source or as destination? The API Consumer can anyway invoke the API for each port. But maybe it is better to support multiple ports. So we could align with QoD using "devicePorts". If yes, for both "source" and "destination"? |
Beta Was this translation helpful? Give feedback.
-
|
Yes @FabrizioMoggio I feel it is better to have a possibility of a range of ports for source and destination ports. Multiple ports will help identify a category of traffic to be influenced. |
Beta Was this translation helpful? Give feedback.
-
|
Implemented with: #249 |
Beta Was this translation helpful? Give feedback.
-
|
Merged rel 0.9.5 |
Beta Was this translation helpful? Give feedback.
-
|
Actually not all is implemented in Rel 0.9.5: #230 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
The Device parameter is as defined in: https://github.com/camaraproject/Commonalities/blob/main/artifacts/CAMARA_common.yaml |
Beta Was this translation helpful? Give feedback.
-
|
As was commented on today's meeting, Device Object will be updated in commonalities v0.4.0, so I agree to be coherent with it |
Beta Was this translation helpful? Give feedback.
-
|
Proposed solution according to: #249 (comment) Proposal: we use Device as defined in Commonalities |
Beta Was this translation helpful? Give feedback.
-
So you are suggesting, for sake of simplicity, in this release, to have just one port for destinationTrafficFilter. This because maybe all the permutations are not valid. Is this correct? We can still have sourceTrafficFilters as list of ports. In this case the API Consumer can ask, with no ambiguity, for flows from those source ports to the one destinatin port specified in destinationTrafficFilter. |
Beta Was this translation helpful? Give feedback.
-
|
For "So you are suggesting, for sake of simplicity, in this release, to have just one port for destinationTrafficFilter. This because maybe all the permutations are not valid. Is this correct?", my answer is "YES" For "We can still have sourceTrafficFilters as list of ports. In this case the API Consumer can ask, with no ambiguity, for flows from those source ports to the one destinatin port specified in destinationTrafficFilter.", my answer is "Not sure if there would be cases where one or more source ports are having a relation with single destination port." In that case even single source port may serve many use cases just that app developers will be need to target one flow at a time. Basically we need assess if such scenario exists for one or more source ports and a single destination port. If not then we can just one port each in source and destination filters in my view. |
Beta Was this translation helpful? Give feedback.
-
I tend to agree with you, I have the same feeling. Just one source port is enough for must use cases. |
Beta Was this translation helpful? Give feedback.
-
@FabrizioMoggio This is the view I was having of the example you had taken. Perhaps it is similar to the way you had thought too. You had mentioned the below scenario: I was interpreting your comment as saying that UPF will route from S_Port_1 to D_Port_1 OR from S_Port_1 to D_Port_2. But as I understand, it is not that UPF will route S_Port_1 to D_Port_1 OR S_Port_1 to D_Port_2 etc. UPF will apply same N6 traffic routing rules on all the traffic flows that have source as S_Port_1 or S_Port_2 and destination as D_Port_1 or D_Port_2. UPF will be configured to look for any traffic flow which has S_Port_1 or S_Port_2 as source AND D_Port_1 or D_Port_2 as destination. Once any of the traffic flows which matches these reaches 5G Core (in the UL direction), UPF will route the traffic to the N6 configured for it in the UPF rules – which is towards the nearest Edge Cloud. Thus, the traffic influence applied is exactly same for all the 4 traffic flows. |
Beta Was this translation helpful? Give feedback.
-
|
exactly we have the same understanding |
Beta Was this translation helpful? Give feedback.
-
|
please note that if we go for just one source port, sourceTrafficFilters, if used, must be equal to the port defined in Device, if used. What happens if are used two different ports? We can document that if they are both valorised, if not equal, the one defined in sourceTrafficFilters, will "win". |
Beta Was this translation helpful? Give feedback.
-
|
I think a device application can have more than one port that it uses and both identifies the same device along with the device IP address. So practically the device out of multiple ports may just want to influence a specific port and that may be different than the port which is used for the device identification. So in my opinion we should not put this restriction of having same port in Device attribute and in the sourceTrafficFilters. Any thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
you are totally right, I'm loosing track of the many ports :-) so:
question:
anyway we still need to decide if sourceTrafficFilters is a list or not. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with Deepak that ports could be different or the same. I understand that the sourceIp:sourcePort Device is just to identify the device and the source/destination traffic filters to identify which Traffic Flow will be affected by TI API. So although the ports are the same, they have different purposes. If only device-port is used, it will be assumed that this is the port of the traffic flow that will be influenced by the TI API. |
Beta Was this translation helpful? Give feedback.
-
|
Agree with above points.
We do have use case for single port in sourceTrafficFilters and a destination port in destinationTrafficFilter. The camera use case mentioned here can be actually extended to say ‘switch all the high-resolution video feeds (multiple source ports) to the Edge video server based on video analysis of a low-resolution video feed’ – which would mean multiple source ports in sourceTrafficFilters. I am also in agreement going for single source and destination port initially and then extending in future to multiple ports based on more use cases being brought up in the group. |
Beta Was this translation helpful? Give feedback.
-
|
According to the above discussion: Conclusion:
|
Beta Was this translation helpful? Give feedback.
-
|
Agree |
Beta Was this translation helpful? Give feedback.
-
|
implemented in: #278 |
Beta Was this translation helpful? Give feedback.
-
it is possible for a Device to setup more data flows using specific Source IP Ports. Currently the TI API doesn't support a Device with source port number.
Are there use cases requiring to support this feature?
Beta Was this translation helpful? Give feedback.
All reactions