RPL: Routing Protocol for Low Power and Lossy Networks Ver. August 3, 2009 Interpret by Rock Hyun Choi From Mobile Embedded System Lab in Daegu University

목차 1. Design Principles 2. Terminology(용어) 3. Protocol model 3.1 problem 3.2 protocol properties overview 3.3 protocol operation

1. Introduction: RPL 1.1 Design Principles RPL이란? LLN(Low power and lossy Netwrok)을 위한 새로운 방법을 제안 방법 제안 이유? 기존의 프로토콜 요구사항들이 잡다하거나 때로는 실제 환경에서 호환해서 사용할 수 없다. Ex) [I-D.ietf-roll-building-routing-reqs] [I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-indus-routing-reqs] [RFC5548]

1. Introduction: RPL 1.1 Design Principles Ex) [RFC5548] Scalability(센서 연동 범위): 최소 100개이상 10000개지원하고 통신 악화되면 안됨 2. Parameter-constrained routing: traffic이 악화되도 긴배터리 수명지원 Support of Autonomous & Alien Configuration Support of highly Directed Info. Flows Support of multicast and anycast Network Dynamicity Latency: 긴급상황에 대한 통신지원 하지만, 각 문서마다 요구 조건을 조금씩 다르고 RPL이 모든 조건을 만족 시키지는 않는다.

1. Introduction: RPL 1.1 Design Principles RPL의 핵심 목표: 1. 제한된 조건 속에서도 작업을 수행 가능하게 하기 위함 RPL은 제공된 설정에 따라(특정 응용과 수행이 얼마나 적합하느냐에 따라) 좀더 최적화 될 수 있다. 2. routing metrics 평가를 할 수 있게 하기위해 특정한 조건들을 수행 할 수 있게 설계되어졌다.

2. Terminology(용어정의) I-D.ietf-roll-terminology 에서 제안 된 것에 확장되었다. Autonomous: 라우팅 프로토콜 능력을 의미. 외부 영향이나 가이드 없이 독립된 객체로 통신 할 수 있는 능력. DAG: Directed Acyclic Graph 사이클 없이, 즉 방향성 없이 모든 가장자리가 특정 영역을 가진다는 의미. RPL에서는 모든 가장자리들이 root node로 가는 길을 가지고 있다. (a DAG root, or sink-typically a LBR) DAGID: DAG member ID Tree와 다르게 여러부모를 가짐

2. Terminology DAG Parent: 하나 또는 다수의 DAGID들은 DAG parents 정보를 가지고 있다. Parents는 하나또는 다수가 될 수 있고 이 설정은 반드시 유지 되어야 한다. DAG Sibling: DAG 내부에서 같은 depth 또는 rank에 위치하는 이웃 노드들. DAG Root: DAG graph의 꼭대기. 모든 노드가 DAG root정보를 적어도 하나이상을 가진다. RPL에서 가장 두드러지는 기능 Grounded: DAG Root로 가는 길을 가진 DAG Floating: DAG Root로 가는 길이 없는 DAG

2. Terminology Inward: DAG Root로 향하는 방향 Outward: DAG Root 반대로 방향으로 가는 DAG P2P: Point to point P2MP: Point to Multipoint Multicast 또는 MPLS Traffic Engineering(RFC4461) 과 비슷한 개념 OCP: Objective Code Point 어떤 RA-DIO 받을 때 쓰는 선정기준

3. Protocol model 3.1 Problem RPL은 기존에 잘 정의 되어 있는 LLN application-specific scenarios를 만족 시키고 다른 어플리케이션 시나리오도 충분히 유용하게 확장할 수 있게 하려한다. Ex) [I-D.ietf-roll-building-routing-reqs] [I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-indus-routing-reqs] [RFC5548]

3. Protocol model 3.2 Protocol Properties Overview 3.2.1 IPv6 Architecture IPv6 architecture를 엄격히 준수한다 RPL 디자인은 아주 높은 신뢰성을 기반으로 한 링크들이 아니며 Lossy links를 기반으로 작동한다. 3.2.2 Path Properties for LLN Traffic Flows MP2P, P2MP 지원 Multiple paths 지원 Class of Service(CoS) 지원 몇몇 노드들에서 빠른 에너지 소모를 피할 수 있는 유용한 방법들 기반

3. Protocol model 3.2.3 Constraint Based Routing RPL은 draft-ietf-roll-routing-metrics 를 만족 시킨다. RPL은 특정 제한과 응용을 위해 최적화를 하는대 OCP가 가이드 하는데 따라 계산하고 다른길들을 설치하게 된다. 보다 자세한 사항은 Section 4에서 다룬다. 3.2.4 Autonomous Operation RPL은 관리자의 관섭 없이도 계산을 수행하고 길을 설치하며 network topology를 스스로 찾아 낸다

3. Protocol model 3.3 Protocol Operation( 프로토콜 동작 ) ①RPL로 동작하는 LLN 노드들은 DAG(Directed Acyclic Graphs)들을 구성 DAG는 MP2P 트래픽 흐름에 적합하다 노드의 흐름은 sink(DAG Root)를 향하고 MP2P를 위한 다중 연결허용 DAG는 트리구조에서 탈락한 싱글노드들 정보는 제공하지 않음 그러나 일시적으로 탈락하거나 load balancing, 또는 짧은 시간동안 접속이 끊어진 경우 링크를 회복을 위한 pre-computed successors(후계자선정) 설정을 제공한다. Load balancing R

3. Protocol model ②Reference topology로 사용할 때 DAG는 노드들의 라우팅 문제를 제한하는 역할을 함: 위치선정 시 반복되는 loop를 회피하기 위한 수단을 제공 구체적인 방법 이후에 다시 언급 DAG를 구성하는 과정에서, RPL은 Destination Adverisement mechanism으로 outward P2MP traffic flow들을 제공 LLN을 DAG로 형성해 나가는 과정에서 outward 방향의 routing이 형성됨 DAG가 유지되는동안 변경사항을 견딜 수 있기 때문에 the Destination Advertisement mechanism이 outward 라우팅 상태가 업데이트 되게 수행

3. Protocol model ③임의의 P2P traffic은 정확한 outward 길을 제공할 능력이 있는 부모노드들에 도착할 때 까지 DAG를 따라 inward로 흐름 현재 RPL은 LLN 노드들에서 임의의 P2P traffic에 보다 최적의 길을 설정하거나 수행하게하는 능력이 있는 어떠한 추가적인 mechanisms이 사용을 제한하거나 구체화 시키지 않음 차후 연구할 과제 높은 수준의 RPL 작동을 위한 영역

3. Protocol model 3.3.1 DAG Construction(구성) 3.3.1.1. Overview of a Typical Case(일반적인 경우) RPL은 하나이상의 base routing topologies 형성: 뿌리내려진 노드들은 최적화된 비용으로 metrics를 구성 DAGs가 ground 상태면 DAG root route 제공: DAG 건설에 노드참여의 일반적인 목표는 grounded DAG로 노드들을 참여시키고 또 노드들을 찾기 위해서 임 Grounded DAG들(root로 가는 길을 가진 노드들)은 Router Advertisements를 때때로 보냄: 잠정적으로 DAG parent로써 DAG root를 평가한 이웃 노드 정보 포함 이 정보가 DAGID, OCP(Objective Code Point)

3. Protocol model 3.3.1.1. Overview of a Typical Case OCP: DAG를 통해 사용되어지는 metrics와 최적화된 목표에 과한 정보를 제공 하나의 루트는 다른 OCP와 함깨 다른 DAG들로 뻣어나갈 수 있음 routing 제한들로 다른 설정을 지원하는게 요구 되기 때문 만약 다양한 DAG root들이 같은 DAG를 DAGID와 함깨 형성한다면? 이 것을 위해 Router Advertisements 보낼 서로 동등하게 전송하기 위한 수단을 반드시 가지고 있어야 함

3. Protocol model 3.3.1.1. Overview of a Typical Case Router Advertisements 노드들 즉 구체적은 내용의 DAGID와 OCP를 전송하는 Routing Advertisements는 DAG정보를 추출할 때 몇 가지의 평가 영역을 고려함 노드는 아마 DAG를 찾으려 함 구체적인 OCP를 advertise, 특정 노드에 의해 해석된 구체적인 라우팅 제한사항에 대한 수행을 반영

3. Protocol model 3.3.1.1. Overview of a Typical Case 노드는 최저 비용이 드는 길을 찾는다. OCP에 의해 지시된 objective function이 만족시킴 몇몇 routing metrics는 [I-D.eftf-roll-touring- metrics]에서 정의 되어 있음 최소비용을 위해 결정되는 사항: 노드 사이의 에너지 소비 최소화, 대기 시간, 배터리를 사용하는 노드 사용 피하기

3. Protocol model 3.3.1.1. Overview of a Typical Case Router Advertisement를 보내는 노드는 잠재적인 DAG parent로 간주됨 그럴 경우, 그 부모 노드는 advertise된 DAGID를 위해 DAG parents의 설정에 advertising node를 추가함 이 때 DAGID에 의해 지명된 DAG에 합류했다고 봄 노드는 특정 DAGID의 DAG parents 설정에 첫번째 DAG parent를 추가했을 때, 노드가 합류(joined) 또는 붙었다(attached)고 함 Potential DAG parent Advertising node

3. Protocol model 3.3.1.1. Overview of a Typical Case 노드에서 특정 DAGID에 DAG parents의 설정으로부터 마지막 DAG parent가 제거 되어졌을 때 노드는 DAGID의 의해 지시된 DAG에서 떠났다(left), 혹은 분리됐다(detached)로 간주 RPL은 반복되는 형태를 피하기 위해 DAGID 내부로 노드들의 움직임과 분리, 그리고 합류를 조정한다.

3. Protocol model 3.3.1.1. Overview of a Typical Case 노드들은 DAG에 합류 하기 때문에 노드들은 Router Advertisement에서 DAG 정보 multicast를 시작할 때 advertise 할 수 있음 이러한 방법이 있기에 노드들을 (DAG root로 부터 outward로 계속 증가하는 depths에) DAG에 합류 시킬 수 있음 노드들이 그들의 DAG parents의 설정을 계속 확장 할 수 있는 이유는 DAG multicasts를 계속 받기 때문 DAG root로 향하는 다양한 길을 생성하기 위해 그리고 이 것은 loop avoidance strategies가 사용되는 동안 이루어 진다

3. Protocol model 3.3.1.1. Overview of a Typical Case OCP에 의해 지시된 기능과 약속된 사항, 그리고 DAG parents로 임명된 metrics에서 받아 들여지는 정보를 사용해서 노드는 depth의 값을 산출할 수 있음 DAG 유지를 협조하는데 사용 됨 DAG parents 확인할 때, 같은 depth의 노드들에서 다른 이웃하는 노드들의 Router Advertisement를 받음 이 방법으로 DAG siblings을 발견할 수 있음 어떤 구체적으로 선택된 사항을 수행함에 따라 DAG parents의 설정을 지시함 이 과정에서 노드는 아마 DAG Siblings의 유사한 지시 설정(정리해서 리스트를 설정)을 추가함

3. Protocol model 3.3.1.1. Overview of a Typical Case a default destination을 위해 DAG parents로 향하려고 하는 traffic 전송수단으로, 노드는 특정 LLN application에 요구되는 MP2P(multipoint-to-point)를 지원할 수 있어야 함 DAG parents와 DAG siblins에서 지시된 설정을 사용해서 노드들은 다양한 path에서 이득을 취 할 수 있음 Ex) parents로 향하는 traffic을 선택할 때 어떤 parent가 선택되어있어도 DAG root에 inward로 가는 보다 가까운 traffic 을 취하는게 보장됨 변화되는 현상으로 인해 parent로 향할 수 없으면 같은 레벨(inwards or outwards도 아님)의 sibling으로 향함

3. Protocol model 3.3.1.1. Overview of a Typical Case Traffic 전송이 Sibling으로 향해 졌을 때, traffic은 2-node loop를 피하기 위해서 같은 sibling으로 다시 향하지 않음 작업의 진행은 parent쪽보다 sibling을 따라 작업이 진행되면 hop 제한이 보다 빠르게 감소되게 선택 되어짐 Forwarding engine은 이러한 예로 유사하게 행동한다. 하지만, forwarding engine의 특정 수행과 path diversity strategies는 이 사항의 범위를 넘어선다 Node Sibling

3. Protocol model 3.3.1.1. Overview of a Typical Case Routing solution의 더 깊이있는 상호작용과 forwarding engine에 대해서는 아직 연구중임 어떻게 metrics에서 변화를 이용하고 반응하는지? 어떻게 forwarding engine에서 routing engine에 의해 L2 triggers와 metrics를 기반으로 successors의 제약된 설정을 이용하는지? L2 trigger: Link-layer Triggers protocol 참고 draft-yegin-l2-triggers-00

3. Protocol model 3.3.1.1. Overview of a Typical Case 이 절차를 이용함으로써 LLN은 제약된 길로 DAG를 만들 수 있음 지시된 노드들로 뻣어 나갈 수 있음 ex)LBR로 부터 다른 노드들과 함께 DAG root로 향해서 조직화 될 수 있음 MP2P traffic은 the destination flows DAG를 따라 root를 향해 흐르려고 함 Traffic을 형성하는 Node들은 DAG의 path diversity를 필요할 때 영향을 끼칠 수 있음 그 때 그 DAG는 RPL에 의해 reference topology로 사용된다. 이 RPL은 추가적인 routing mechanisms을 설계해서 LLN rouging problem을 억제시킨다.

3. Protocol model 3.3.1.2. Futher Operation sub-DAG는 DAG 내부에서 DAG root로 향하는 길을 가지고 있을 것이고, 노드에서 보다 깊은 depth를 가진 다른 노드들에 대한 설정임 DAG에서 Depth란 한 노드가 특정 노드로 sub-DAG를 형성하고 있다는 것을 의미. 그 sub-DAG을 형성하는 특정 노드는 보통 보다 깊은 depth를 가지는 경향이 있음. Siblings로 향하는 길은 이 설정에 포함되어있지 않음. 보다 자세한 사항은 Appendix B참고 특히 노드 24가 34, 44, 45를 포함하고 있다는 것을 참고 할 것

3. Protocol model 3.3.1.2. Futher Operation Appendix B 11 12 13 21 22 LBR 11 12 13 21 22 23 24 31 32 33 34 41 42 43 44 45 51 52 53 54 55 56 Appendix B

3. Protocol model 3.3.1.2. Futher Operation DAG가 floating 되면 default route를 제공하지 않음 DAG에서 떨어져나간 노드와 sub-DAG에서 network topology의 coordinated reconfigurations 동안 Floating DAG에 직면하게 됨 이 상태로 일시적으로 Floating DAG가 됨 그리고 다른 지역에서 다시 grounded DAG으로 다시 재 합류 함 이 조정은 LLN의 변화하기 쉬운 loops의 구조를 극복하기위해 시도하는 것 DAG or sub-DAG는 아마 네트워크 요소의 결함으로도 floating됨

3. Protocol model 3.3.1.2. Futher Operation 노드는 보통 적어도 하나의 DAG에 합류 (일반적으로 LBR에 합류하나 꼭 필요한 것은 아님) 이 특성은 multiple DAGs에 합류하는 것을 방해하지 않음 특정 application은 제한사항들을 만족시키기위해 multiple DAG에서 membership을 유지하는 노드를 요구할 수도 있음 ex) 비록 RPL mechanisms이 확연히 이 프로토콜과는 다르지만, 다른 종류의 traffic을 지원할 때 유사한 개념으로는 MTP(Multi-topology routing) by ISIS[RFC5120] or OSPF[RFC4915] 이 있음 이 경우를 지원 하려면 RPL 수행은 반드시 독립적으로 필요한 정보와 각각의 DAG의 상태를 병렬로 유지해야 함 Competing constraints이 있는 경우도 반드시 같은 DAG root로 향하는 것은 만족되어져야 하고, OCP정의는 달라야 하며, Multiple DAGs의 유지를 조정하는것을 도와야 함

3. Protocol model 3.3.1.3. Router Advertisement – DAG information option RA-DIO IPv6 Router Advertisement mechanism[RFC4861] DAG을 생성하고 유지하기 위해 RPL에서는 IPv6 Router Advertisement mechanism[RFC4861]이 사용됨 DAGs의 유지와 형성을 용이하게 하기위해 DAG information Option(DIO)는 IPv6 Router Advertisement message를 증가시킴 RA DIO

3. Protocol model 3.3.1.3. Router Advertisement – DAG information option(RA-DIO) DIO에서 Information의 흐름은 아래 내용을 포함: ◆ DAGID는 DAG root로부터 근원이 되는 DAG을 확인하는데 사용. 일반적으로 DAG root의 IPv6 address. 아마도 동등하게 하기 위해 테스트됨 ◆ Objective Code Point(OCP)가 아래에 설명됨 ◆ Depth 정보(nodes에 사용되어지)는 DAG 내부의 다른 노드들과의 관계를 규명함 ex)parents, siblings, or children. 그것의 유도가 비록 OCP에서 구체화되어 하나 또는 그 이상의 metrics가 유사하게 관련되어 있어도,이 것은 metric이 아님. Path maintenance에 연계되 있을 때, 대체 successor 규정을 지원하고 loop avoidance strategies를 지원하는데 사용

3. Protocol model 3.3.1.3. Router Advertisement – DAG information option(RA-DIO) ◆ DAG root로부터 시작되는 연속된 수치들은 loops를 피하는 방법으로 topology 변화를 조절하고 종속된 sub-DAGs의 확인을 돕는대 사용 ◆ DAG의 표시, ex) grounded or floating ◆ DAG configuration parameters ◆ A vector of path metrics. [I-D.ietf-roll-routing-metrics]에서 다루어 졌고 이 metrics는 아마도 자료가 누적되고 또 아마 최대, 최저, or average scalar value, or link property를 보고 함 ◆ 추가된 destination prefixes 목록은 DAG root를 경유해 도착

3. Protocol model 3.3.1.3. Router Advertisement – DAG information option(RA-DIO) Router Advertisement는 언제든 변화가 발견되면 DAG에서 발생하고 그 노드는 DAG 지역에서 일치되지 않은 것을 결정할 수 있음 DAG는 Router Advertisement가 발생할 때 주기가 안정화되기 때문에 RA(?)가 발생을 감소되게 설정하고 DAG maintenance의 steady-state overhead를 감소시킨다 Router Advertisements의 주기적인 발생(불일치에 대한 응답으로 실행된 Router Advertisement를 따라)은 불안정한 링크들의 상태에서 RPL을 작동하는 하나의 특징이다. RA-DIO와 권련된 mechanisms은 Section5에 보다 더 자세한 내용들이 언급되어 있다

3. Protocol model 3.3.1.4. Objective Cope Point(OCP) OCP는 DAG root에서 만들어지고, DAG내에 사용되는 최적화된 기능들을 컨트롤하고 전달하는 것을 도움 그 OCP는 TAB Registry 내부에 reference 역할을 하는 것으로 파악되어 질 수 있음. 다음은 배치된 OCP의 예는 반드시 나타내야 함: ◆ DAG 내부에 사용되는 mectics의 설정 ◆ DAG를 최적화하기위해 the least cost constrained paths를 결정하는데 사용되는 objective functions ◆ DAG Depth를 산출하는 function ◆ DIO내부에서 propagation을 위한 derived metrics를 건설 하는데 사용할 functions

3. Protocol model 3.3.1.4. Objective Cope Point(OCP) For example, Objective code point는 아마도 DAG에서 사용중인 ETX를 가리키고, 최적화된 목표는 ETX를 최소화 하는 것이며, DAG Depth를 ETX에 동등하게 하며, DIO propagation에서는 가장 선호되는 parent 노드에 링크되는 advertiesed ETX를 추가하는 게 필요 정의된 OCP들을 사용해서 모든 노드들의 특정 수행이 이해되어 질 수 있고, DIO에서 그 들에게 전달하며, RPL 노드들은 아마도 다양한 application의 사용과 특정 metrics와 goals의 수행을 최적화하는 LLN을 구축하는 작업을 함 NOTE: NULL OCP는 반드시 초기 설정이 잘 정의 되어져 있어야 함. NULL CODE POINT는 이후에 지원되지 않는 code point가 포함된 DIO와 노드가 마주 했을 때 RPL의 행동을 정의하는대 사용되어 짐

3. Protocol model 3.3.1.5. Selection of Feasible DAG Parents DAG에 합류하는 노드들의 결정은 하나 또는 그 이상의 특정 OCP값들에 의해 지시되어진 노드들의 특정 policy functions의 수행에 따라 최적화 되어질 것임 Ex) 한 노드가 bandwidth metric(OCP-1)을 최적화하는 하나의 목표를 위하 설정되어 지고, 그리고 reliability metric(OCP-2)를 위한 최적화가 목표가 병렬로 설정 됨 그래서 병렬인 두 개의 DAGs은 LLN에서 유지되고 구성되어짐 DAG-1은 OCP-1에 의해 최적화 되어지고 반면 DAG-2는 OCP-2에 의해 최적화되어짐 그 때 노드는 DAG parents의 두가지 병렬 설정을 아마 유지함

3. Protocol model 3.3.1.5. Selection of Feasible DAG Parents Traffic의 경우를 확인 해 보면, 이 것은 아마도 IPv6 header 내부의 traffic marking을 기반으로 하는 적절한 constrained DAG을 따라 향함. 노드가 그의 neighbors로부터 RAs를 받기에, 이 과 정은 아마 그들의 DIOs를 처리 함. 이 시간에 노드는 아마 다음과 같은 상황을 고려할 수 있음: ◆ 이웃 노드가 충분히 안정적으로 듣고 있는지? Metrics가 충분히 안정적인지? 지역 범위의 신뢰성이 이웃 노드가 고려하는 만큼 설립되어 있는지? 이웃 노드로 참여하는 설정이 잘 고려되어 있는지? ◆ specific policy(OCP goal)을 수행하는 협의에는, 이웃 노드가 constrained-path perspective로 부터 실현 가능한 parent인지?

3. Protocol model 3.3.1.5. Selection of Feasible DAG Parents ◆ specific policy(OCP goal) 수행에 따라, 이웃 노드가 DAG에서 보다 최적화된 위치를 제공하는가? ◆ 이웃 노드는 DAG에서 이웃(sibling)인지? 고려된 사항들을 기반으로, 노드는 DAG parents 설정으로 이웃노드들을 결합. 노드가 empty DAG parent set에 첫 번째 DAG parent로 삽입될 때, DAG로 합류 될 수 있음. DAG parent set이 업데이트 된 후에, 노드는 depth 값을 결정하기 위해 OCP에 의해 지시된 depth computation function 정보를 구하고, 그리고 그 노드 스스로의 DIOs를 내뿜었을 때 advertise를 그 이후에 함.

3. Protocol model 3.3.1.5. Selection of Feasible DAG Parents Depth value의 일반적은 특성은 노드에 의해 나타내어지며 어떤 DAG parents 보다도 일반 노드의 값이 더 큼 노드는 OCP goals로 부터 가장 좋은 DAG parent set을 유지하며, 또한 DAG parent set에서 가장 큰 depth value를 가짐(?). 노드에서 depth가 덜 깊고 안정적인 모든 이웃 노드는 잠정적으로 DAG parents로 고려되어질 수 있음. 같은 depth를 가진 모든 이웃 노드들은 DAG에서 보통(may) sibling으로 고려되어짐(비록 그 노드들이 공통된 parent를 가지고 있지 않더라고 그들은 꾸준히 DAG root로 향하는 다양한 길을 제공함). Depth에 대해 보다 관련된 영역은 후에 Section 3.4.1에서 다루어짐

3. Protocol model 3.3.1.5. Selection of Feasible DAG Parents 3.3.1.5.1 Example 어떤 DAG에도 속하지 않은 (N)이란 노드를 가정해보자. 그리고 범위 내에 A, B, C, D ,E 노드들이 있다. ETX는 “Blue”라고 간주된 노드를 회피하는 paths 이고 최소화된다. 이러한 policy가 정의된 OCP를 사용하게 모든 노드들을 설정해 보자. OCP에 의해 지시된 depth 연산을 길을 따라 모아진 ETX를 반사 시키자. 노드 N과 A-E의 이웃노드들의 링크에 1이란 ETX를 가지게 하자(노드 N이 몇가지 특정 방법으로 수행한 것을 통해 배운 것으로). 노드 N은 근처의 DAGs을 통해 찾은 Router Solicatations(간청)을 보내는 것을 설정 되어 지게 하자.

3. Protocol model 3.3.1.5. Selection of Feasible DAG Parents ◆ 노드 N은 Router Solicitation을 전송 ◆ 노드 B가 응답. N은 DIO를 조사하고, 그리고 B는 Depth 4에 DAGID 1의 멤버이고 ‘Blue’가 아니라는 것을 배움. N은 이 것을 기록하지만 그러나 아직 굳게 믿지는 않음 ◆ 유사하게 N은 depth 9의 A, depth 5 C, depth 4 E를 각각 듣는다 ◆ 노드 D가 응답. 노드 D가 DIO를 가지고 있음. DIO는 depth2의 DAGID 1의 멤버라는걸 가르키지만, 그러나 이 것은 ‘Blue’라고 간주 된 것을 운반해옴. N의 policy function에 따라 노드 D를 제거하고 더 이상의 고려사항이 주어지지 않음

3. Protocol model 3.3.1.5. Selection of Feasible DAG Parents ◆ 노드 D가 응답. 노드 D가 DIO를 가지고 있음. DIO는 depth2의 DAGID 1의 멤버라는걸 가르키지만, 그러나 이 것은 ‘Blue’라고 간주 된 것을 운반해옴. N의 policy function에 따라 노드 D를 제거하고 더 이상의 고려사항이 주어지지 않음 ◆ 이 과정은 DAGID 1에 합류를 결정하는 수행은 노드 N(특정한 수행정책을 기반으로)이 충분한 신뢰도를 가질 때 까지 계속 수행한다. 노드 N이 가장선호하는 parent로 노드E로 하자. ◆ N은 E(depth 4)를 DAGID 1을 위한 DAG parent로 추가한다. OCP에서 정해진 mechanisms을 따르고, 그리고 N과 E의 링크를에 ETX 1이 주어진다. 현재 노드 N은 DAGID 1에서 depth 5.

3. Protocol model 3.3.1.5. Selection of Feasible DAG Parents ◆ N은 B(depth 4)를 DAGID 1을 위한 DAG parents의 설정을 추가 ◆ N은 C의 sibling, 둘 다 depth 5 ◆ N의 traffic은 지금 부터 B와 E를 통해서 DAGID 1을 따라 inward로 하려고 함. 몇 몇의 경우, B와 E가 try 이거나 fail일때, N은 아마 또한 inward로 진행을 만들지 않고 sibling인 C로 traffic이 전해짐, 그러나 또 한 C또는 다른 following successor도 inward progress를 만들 수 있는 계획이 있다.

3. Protocol model 3.3.1.6. DAG Maintenance 노드가 DAG 내부에서 움직일 때, 그 움직임은 특정 DAGID에서 DAG parents의 설정이 업데이트 되는 것으로 정의되어 진다. Depth의 모든 움직임이 변화를 일으키는건 아니다. Context of DAG에서 점프는 새로운 DAGID를 부여하고 old DAGID가 new DAGID로 교체 독특하게, old DAGID가 떠나면, 모든 소속된 parent가 더 이상 실현가능하지 않고 새로운 DAGID가 합류한다. 노드가 DAG에서 DAG parent를 따를 때, 이 DAG parent는 DAGID가 이미 변했다는 것을 의미한다. 그리고 그 노드는 DAG parent를 유지하기 위해 그 자신의 DAGID를 업데이트함

3. Protocol model 3.3.1.6. DAG Maintenance ◆ 동결된 sub-DAG은 한 노드의 sub-DAG에서 노드들의 부분 집합이다. 그리고 그 한 노드는 노드에서 변화를 알렸던 노드고 변화과 일관된 방법인 상태에서 노드를 따르는 것을 선택 Ex) preparation for a coordinated move Sub-DAG의 변화를 감지하고, 노드를 따르는 것보다 다른 옵션을 가진 노드들은 동결된 sub-DAG의 부분이 되어져서는 안된다. EX) 한 노드 즉, 다른 부모 노드를 통해 기존의 DAG에 접촉하는 것이 남겨질수 있는 노드 다른 예제는 Section 3.4.1.1에서 찾아 질 수 있음

3. Protocol model 3.3.1.6. DAG Maintenance ◆ 노드가 DAG에서 보다 더 높은 positions을 제공하는 새로운 참여자 이웃을 조우했을 때, 즉각 DAG parents의 설정으로 그들을 편입시킨다. 이 경우에 노드는 가장선호되는 부모들을 선택하고, 더 깊은 노드들을 제거하고, 그 들 자신의 advertised depth가 감소할 가능성이 있다. 이 경우가 DAG을 따라 inward로의 움직임이다, 그리고 loop avoidance를 위한 추가적인 어떠한 협력도 요구하지 않는다. ◆ 만약 노드의 DAG parent 설정이 완벽히 제거되면, 노드는 DAG으로 부터 분리된다. 그리고 그 스스로 floating DAG의 root가 된다.(그래서 frozen sub-DAG을 만든다). 그리도 아마 가능하다면 lower point에 기존의 DAG에 다시 합류한다.

3. Protocol model 3.3.1.6. DAG Maintenance ◆ 노드가 candidate parents (다른 DAG에서 또는 다른 DAG에 합류하기 위해 현재 DAG을 떠나기로 결심한 노드) 를 조우하면, loop avoidance 관여없이 안전하게 이루어 질 수 있을 것이다. 그러나, 현재 DAG에서 즉각 돌아 올 수는 없을 것이다, 왜냐면 그 움직임이 loops의 생성을 발생시키기 때문이다. ◆ 한 노드가(아마 frozen sub-DAG에 연관된) 다른 DAG으로 점프할 때, 그 움직임은 DAG Hop timer에의해 조정된다. DAP Hop timer는 노드(즉, new DAG의 sink에서 더 가깝게 첫 번째로 점프해서 합류하게 하는 것)을 허락한다. 그리고 그 때 그 들 뒤에의 dependent nodes 끌어 들인다. 그래서 새로운 DAG로 frozen sub-DAG의 합류를 효과적으로 조절하려고 시도한다. 이 mechanism에 관해 더 나은 설명은 Section 3.4.3에서 찾을 수 있다. DAG 발견과 maintenance의 룰들과 처리는 Section5에 포함된다. Appendix B에서 이 것의 예시가 있다.

3. Protocol model 3.3.2 source Routing ◆ Source Routing mechanism for RPL은 현제 연구 중이다. ( 091004 ver도 같음)

3. Protocol model 3.3.3. Destination Advertisement RPL이 DAGs을 구성하기 때문에, 노드들은 sink에 traffic을 보내기위해서 default routes 의 설정을 배울 수 있다. 그러나 이 mechanism 혼자서는 DAG root로 부터 outward의 P2MP traffic 지원하는 것이 적합하지 않다. Destination Advertisement mechanism은 RPL에 의해 outward flow의 지원하는 routing state를 건설하는대 종사한다. 3.3.3.1 Destination Advertisement Option(DAO) Destination Advertisement Option은 DAG root를 향해 DAG의 inward로 Destination information을 전달하는대 사용되어 진다. DAO에서 전달되는 정보는 다음을 따른다.

3. Protocol model 3.3.3.1 Destination Advertisement Option(DAO) 3.3.3.1 Destination Advertisement Optin(DAO)