1

Assume i have an IN-AE, IN-CSE & MN-CSE. The MN-CSE has a container resource that is announced in the IN-CSE. The IN-AE, via the link in the announced resource, creates a subscription on the container in the MN-CSE, and the notificationURI of that subscription is the POA of the IN-AE.

What is the mechanism by which the MN-CSE is able to route notifications back through the IN-CSE to the IN-AE?

For example, let's say i have a container in my MN-CSE at /mn-cse/ae1/container and my IN-AE POST the following subscription to the IN-CSE:

POST http://in-cse-host/mn-cse/ae1/container?rcn=2 HTTP/1.1
X-M2M-Origin: ae
X-M2M-RI: ri1

{
  "sub": {
    "enc": {
      "net": [
        3
      ]
    },
    "nu": [
      "http://in-ae-host/notify"
    ],
    "nct": 1
  }
}

NOTE: the nu there is the IN-AE's POA, and it's how the IN-CSE can talk to the IN-AE.

However, let's say the MN-CSE doesn't talk HTTP, or can't route to in-ae-host. How does the MN-CSE know how to route notifications with that nu back to the correct AE?

Spongman
  • 9,665
  • 8
  • 39
  • 58

1 Answers1

0

A CSE must forward any request for which it is not the target, to the target/destination CSE (transit requests). See TS-0001, Table 8.2.1.0-1 "Accessing Resources in different CSEs, from Registree to Registrar CSE", for detailed descriptions on no-hops (target CSE is the same CSE), 1-hop (either direct registrar or direct registree CSE of the CSE), and multi-hop (not a direct registrar or registree CSE) communication.

Answer to the updated question

However, let's say the MN-CSE doesn't talk HTTP, or can't route to in-ae-host. How does the MN-CSE know how to route notifications with that nu back to the correct AE?

What happens is this: the MN-CSE starts to create a subscription under the container /mn-cse/ae1/container. One of the step in the process involves a verification request to all the notification URI's in nu. Since this fails (MN-CSE cannot reach the target for whatever reasons) the verification request fails and the subscription is not created.

Andreas Kraft
  • 3,754
  • 1
  • 30
  • 39
  • i'm talking about notifications that target a notificationURI, not requests that target a resource. i'll clarify my question. – Spongman Aug 26 '20 at 00:57
  • A soultion would be if the subscription's *nu* would not contain a direct (http) URL, but a SP-relative ID of the IN-AE, like "/in-cse/in-ae". The MN-CSE would then forward the notification by whatever (e.g.non-http) communication means to the IN-CSE. The IN-CSE is then responsible to send the notification to the IN-AE (bc the IN-CSE must know how to communicate with the IN-AE). – Andreas Kraft Aug 28 '20 at 14:13
  • right, but doesn't that require the IN-AE to know whether or not some arbitrary set of intermediate CSE's can talk to each other using some protocol? or should an IN-AE always assume that a remote CSE can't route to it? – Spongman Aug 31 '20 at 19:50
  • Good question. I would say that this depends on the deployment architecture.The direct (http) notification URI is an allowed and convenient shortcut when it is clear that all CSE's can freely communicate (also with external entities). But the advantage of a oneM2M system is that it can handle the communication for its entities, even when there is no always-on connection between the CSE's. So yes, if you want to be on the safe side let the CSE's handle the notifications. – Andreas Kraft Aug 31 '20 at 20:15
  • seems like a pretty big hole to me. sometimes you can specify a notificationURI, except when you can't, but you don't necessarily know when that is - it depends on the intermediate CSEs and some private knowledge they have between them. does that mean if I'm an AE vendor, i can't rely on being able to use a different notificationURI in general (because i may be deployed in a configuration where it can't be used), and i should just rely on the AE having a configured POA instead? – Spongman Sep 04 '20 at 02:48
  • I don't see a problem here. Those are typical attributes that are configured during deployment and bootstrapping, or during the actual operation. With the indirections there imho is enough flexibility to fulfil the use cases. The "private knowledge" lies within the infrastructure. The role of the vendor is not deployment and operation. If the vendor provides a "vendor cloud" (as many consumer-level products do) the vendor becomes the operator and has full control. – Andreas Kraft Sep 04 '20 at 08:33