Routing Problem of the Current Architecture Group Name: ARC Source: Hongbeom Ahn, LG Electronics, Meeting Date: 2014-02-07 Agenda.

Slides:

Advertisements

Similar presentations

Access Control Mechanism Discussion

Advertisements

CMDH Refinement Contribution: oneM2M-ARC-0397

oneM2M and AllJoyn Interworking

SEC Clarification Group Name: WG4 (SEC-2014-xxxx) Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:

Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.

Access Control Mechanism for User Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: Agenda Item:

Problem of Current Notification Group Name: ARC WG Source: Heedong Choi, LG Electronics, Meeting Date: ARC 9.0 Agenda Item: TBD.

Problem of non-Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.0 Agenda Item: TBD.

Service Layer Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP16 Agenda Item:

REQ WG Reuse of underlying networks, 3GPP

REQ WG Reuse of underlying networks, 3GPP

Discussion on oneM2M HTTP Binding Interoperability Test Spec.

Multi-Link Devices Group Name: WG1 Source: Kaonmedia, KETI Contact: Hwang Kwang Tae Yong-Suk Park

2-levels Access control for HTTP binding Group Name: WG4 (& WG2/WG3 for information) Source: Shingo Fujimoto, FUJITSU, Meeting.

CMDH Policies Contribution: ARC R03-CMDH_Policies.ppt Source: Josef Blanz, Qualcomm UK, Hongbeom Ahn, LG Electronics,

oneM2M-OIC Interworking Technical Comparison

Common Service Entities

Step by step approach Group Name: WG2

In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:

End-to-End security definition Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting Date:

PRO R01-URI_mapping_discussion Discussion on URI mapping in protocol context Group Name: PRO and ARC Source: Shingo Fujimoto, FUJITSU,

3GPP Rel-13 Interworking discussions

In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:

Answer the Questions Regarding Pending Issues on Access Control Group Name: WG4 SEC Source: LG Electronics Meeting Date: Agenda Item: SEC#11.4.

Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.

TS0001 Identifiers way forward Group Name: WG2 Source: Elloumi, Foti, Scarrone, Lu (tbc), Jeong (tbc) Meeting Date: Agenda Item: ARC11/PRO11.

App-ID Discussion Group Name: ARC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 31 July 2014 Agenda Item: TBD.

Fuctional Procedure for oiC interworking

Supporting long polling Group Name: ARC WG Source: SeungMyeong, LG Electronics, Meeting Date: x-xx Agenda Item: TBD.

HUAWEI TECHNOLOGIES CO., LTD. Slide title :40-47pt Slide subtitle :26-30pt Color::white Corporate Font : FrutigerNext LT Medium Font to be used by customers.

Step by step approach Group Name: WG2 Source: Michael hs. Yang, LG uplus, Jaeseung Song, NEC Europe, Meeting.

Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.

Matching Resources with CSFs Group Name: WG2 (ARC) Source: Hongbeom Ahn, LG Electronics, Meeting Date:

Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.2,

OIC INTERWORKING OPERATIONAL PROCEDURE (ADDRESSING AND DISCOVERY) Group Name: Architecture WG Source: Kiran Vedula, Samsung Electronics,

Issues pertaining to IOP test Group Name: TST Source: Jiaxin Yin, Huawei Technologies Co., Ltd. Meeting Date: Agenda Item: TBD.

M2M Service Session Management (SSM) CSF

M2M Service Subscription Profile Discussion Group Name: oneM2M TP #19.2 Source: LG Electronics Meeting Date: Agenda Item:

Realizing Ms Interface with OMA DM Group Name: MAS WG Source: Seungkyu Park, LG Meeting Date:

SE abstraction scenarios Group Name: SEC Source: Claus Dietze, Giesecke & Devrient Meeting Date: Agenda Item: WI SE abstraction.

Communication and Security in Machine-to-Machine Systems Date │ Reporter │ 李雅樺 1.

Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: Agenda Item: Security API.

Streaming Session Support in oneM2M Framework Group Name: WG2 Source: George Foti, Ericsson Meeting Date: Work Item :WI GPP_Rel13_IWK.

3GPP SCEF Interworking Discussions

oneM2M based IoT Platform Development of SK Telecom

Authorization Architecture Discussion Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 28 MAY, 2014 Agenda.

CMDH and Policies Contribution: oneM2M-ARC-0603

FUCTIONAL ARCHITECTURE FOR OIC INTERWORKING Group Name: Architecture WG Source: Jieun Keum, Samsung Electronics,

Issues about management Group Name: MAS9.2 Source: Jiaxin Yin, Huawei Technologies Co., Ltd., Meeting Date: Agenda Item:

Consideration Security Issues on Registration Group Name: WG4 (SEC) Source: Shingo Fujimoto, FUJITSU, Meeting Date:

Reasons for CSF Clean-up (Issues & Next Steps) Group Name: WG2 Source: Syed Husain – NTT DOCOMO Meeting Date: (ARC_9.3) Agenda Item: 6 DOC#:

WG1 - REQ Progress Report at TP #11 Group Name: WG1 REQ (Requirements) Source: WG1 Vice Chairs Meeting Date: to Agenda Item: TP#11,

Management CSF(s) Architectural choices Group Name: WG2 (ARC), WG5(MAS) Source: Catalina Mladin, InterDigital Comm., Meeting.

Directions for Release 3 Group Name: SEC Source: NEC Europe Ltd. Meeting Date: SEC22, Agenda Item: Discuss directions.

Introduction to Service Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:

Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.

Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.

FUCTIONAL ARCHITECTURE FOR OIC INTERWORKING Group Name: Architecture WG Source: Jinhyeock Choi, Samsung Electronics,

Resource subscription using DDS in oneM2M

3GPP MBMS protocol stack

Provisional Architecture for oneM2M

CSE Retargeting to AE, IPE, and NoDN Hosted Resources

CSE Retargeting to AE, IPE, and NoDN Hosted Resources

Group multicast fanOut Procedure

Possible options of using DDS in oneM2M

Proposed design principles for modelling interworked devices

MAF&MEF Interface Specification discussion of the next steps

Proximal IoT Interworking solution discussion

Considering issues regarding handling token

3GPP V2X Interworking Potential Impact

Presentation transcript:

Routing Problem of the Current Architecture Group Name: ARC Source: Hongbeom Ahn, LG Electronics, Meeting Date: Agenda Item: Contribution

Service Layer Routing in ETSI TC M2M © 2014 oneM2M Partners ARC Routing_Problem 2 DA GSCL GA Gateway Device NSCL NA M2M Server Network Application DSCL DA Device NSCL NA M2M Server Network Application A GSCL or DSCL is only connected with a NSCL over service layer domain Only 1 SCL-hop routing case is existed

Problem Statement (1/5) However, Based on our current architecture model oneM2M system have more than 1 CSE-hop routing cases – A message is forwarded over multiple Mcc reference points Due to the fact, our architecture might have some problems – A message is (1) forwarded over more than a Mcc reference point and a Node in the path has (2) multiple-outgoing paths CSE 1 AE CSE 3 CSE 4 CSE 5 IN MN ASN From CSE 1 to CSE 4 : 3 CSE-hops routing case CSE 2 MN © 2014 oneM2M Partners ARC Routing_Problem 3

CSE 6 CSE 5 CSE 3 IN MN CSE 4 MN MN-CSE 5 has multiple outgoing paths toward 1)MN-CSE 3 2)MN-CSE 4 CSE 1 AE ASN 1 CSE 2 AE ASN 2 Case 1 (Proper Next Hop) – A message is sent from IN-CSE 6 to ASN-CSE 1 Problem Statement (2/5) In this case, MN-CSE 5 needs to determine the proper next hop for the successful message routing in this case, the proper next hop is MN-CSE 3. To determine this, MN-CSE 5 must have a sort of routing information, similar to IP routing table © 2014 oneM2M Partners ARC Routing_Problem 4

CSE 1 AE CSE 2 CSE 3 ASN MN CSE 5 MN CSE 6 MN In this case, MN-CSE 2 needs to determine the proper next hop for routing in this case, the proper next hop is MN-CSE 3 for effective routing (if the cost of each hop is the same) MN-CSE 2 has multiple outgoing paths toward 1)MN-CSE 3 2)MN-CSE 5 CSE 7 IN Problem Statement (3/5) Case 2 (Effective Routing) –A message is sent from ASN-CSE 1 to IN-CSE 7 © 2014 oneM2M Partners ARC Routing_Problem 5

CSE 1 CSE 2 IN MN CSE 3 MN IN-CSE 1 has multiple outgoing paths toward 1)MN-CSE 2 2)MN-CSE 3 CSE 4 AE ASN CSE 5 AE ASN Problem Statement (4/5) Case 3 (Proper Next Hop) –A message is sent from IN-CSE 1 to ASN-CSE 4 In this case, the IN-CSE 1 needs to determine the proper next hop for the successful routing in this case, the proper next hop is MN-CSE 2 and the IN-CSE 1 must have all the registration information of Node behind the MNs © 2014 oneM2M Partners ARC Routing_Problem 6

Summary of the problem statement – In our current architecture – When a message is (1) forwarded over more than a Mcc reference point and an entry/intermediate Node in the path has (2) multiple- outgoing paths – The Node needs to determine the proper next hop (CSE) for successful and effective routing Difficult to support this case described above – Lack of time to fully develop – However, this current TS-0001 needs to be fixed to solve this problem – Better to simplify our current architecture for technical consistency Problem Statement (5/5) © 2014 oneM2M Partners ARC Routing_Problem 7

Proposals (1/2) To simplified our solution No MN to MN connection in release 1 – Only ASN or ADN – MN – IN connection – Complex configurations for subsequent release – Relevant figures and normative texts shall be modified – Please see the relevant contribution © 2014 oneM2M Partners ARC Routing_Problem 8

Proposals (2/2) Limitation on multi-hop routing case – The Local CSE shall ensure the selection of the proper next hop among the registered Intermediate CSEs. The selected next hop shall be registered with the Hosting CSE and shall forward the request to the Hosting CSE. – Please see the relevant contribution CSE 1 CSE 2 IN (Local CSE) MN (Intermediate CSE) CSE 3 MN CSE 4 AE ASN (Hosting CSE) CSE 5 AE ASN Proper Next Hop © 2014 oneM2M Partners ARC Routing_Problem 9

CSE 2 CSE 3 IN (Intermediate CSE) MN (Intermediate CSE) CSE 4 MN CSE 5 AE ASN (Hosting CSE) CSE 6 AE ASN Proper Next Hop CSE 1 AE ASN (Local CSE) Plus, this configuration is also applied for the second proposal – The Intermediate CSE shall ensure the selection of the proper next hop among the registered Intermediate CSEs. The selected next hop shall be registered with the Hosting CSE and shall forward the request to the Hosting CSE. © 2014 oneM2M Partners ARC Routing_Problem 10