General

สรป Paper “A Delay-Tolerant Network Architecture for Challenged Internets”

Internet ประสบความสำเร็จในวงกว้าง แต่สำหรับข้อจำกัดที่ตัวอุปกรณ์ (limited power, lacking memory) หรือข้อจำกัดใน Network Scenario ที่ต่างประเภทกัน ยังคงเป็นอีกประเด็นที่ DTN ให้ความสนใจว่า จะทำงานร่วมกันได้ (Interoperability) ได้อย่างไร เช่น การสื่อสารระหว่าง Computer Network ติดต่อกับ Wireless Sensor Network

การจะก่อให้เกิดการติดต่อสื่อสารโดยอิสระจากสภาวะแวดล้อม จำเป็นต้องมีวิธีการเพิ่มเติมเข้ามาช่วย จึงได้ออกแบบ End-to-End Architecture ที่อิงกับการรับส่ง Asynchronous Message โดยไม่ต้องใส่ใจในข้อจำกัดการสถาปนาเส้นทาง หรือต้องลงทุนไปเพื่อเพิ่ม Resource ของทุก Node ทั้งหมดใน Network

Paper นี้ต่อเนื่องจาก Paper ” Delay-Tolerant Networking: An Approach to Interplanetary Internet” ที่ได้สรุปโดยคร่าวถึงประเด็นที่น่าจะให้ความสนใจสำหรับ DTN .. Kevin Fall ได้นำประเด็นทั้งหมดที่ว่า มาเน้นย้ำให้ชัดเจนยิ่งขึ้น ด้วยการยกตัวอย่างแต่ละ Element ในสถานการณ์ที่แตกต่าง ไม่เฉพาะใน Interplanetary .. ดังนั้นจึงจะขอละเนื้อหาที่ซ้ำซ้อนบางส่วน และยกเอาส่วนประเด็นที่น่าสนใจมากล่าวถึงเท่านั้น

A Delay Tolerant Message Based Overlay Architecture

End-node รับส่งข้อมูล, Message, ถูกเรียกว่า “Bundle” .. ผ่าน DTN .. ผ่าน Router – Gateway ซึ่งถูกเรียกว่า “Bundle Forwarder”, “DTN Gateway” ระหว่างสอง Network (Region) ที่มีความแตกต่างกัน

Overlay Architecture, DTN ถูกตั้งใจสร้างให้สามารถใช้งานกับ Protocol ต่างๆ ใน Network ที่หลากหลาย ซึ่งมีอยู่แล้วได้ โดยจัดให้มี “Store & Forward Gateway” ทำหน้าที่เป็นตัวกลางผ่านข้อมูลระหว่าง Network นั้น

หลากหลาย Network ที่ต่างสภาวะแวดล้อม ต่างมีความพิเศษที่ชุด Protocol และ Naming Semantic (ความสำพันธ์ของการตั้งชื่อ ??) ที่ถูกพัฒนาให้เหมาะกับ Application ใน Network นั้น จึงต้องมี DTN Gateway อยู่ ณ. จุดเชื่อมต่อระหว่าง Region ทำหน้าที่ ผสานให้ทำงานร่วมกันที่ได้

Regions and DTN Gateways

ตัวอย่างการทำงานจากภาพข้างต้น, “Region” = (A, B, C, D) และ “DTN Gateway” = (2, 3, 5, 6), มี Region A และ C เป็น Internet ปรกติ .. ทำงานร่วมกับ Region B, มีรถรับส่ง พาข้อมูล ทำให้ DTN Gateway 3, 5 จำเป็นต้องทราบถึงช่วงเวลาที่ Channel Available ซึ่งปรกติแล้วจะสามารถคาดการณ์ได้ แต่บางครั้งอาจคาดเคลื่อน เนื่องมาจากรถติด .. และทำงานร่วมกับ Region D, มีดาวเทียมโคจรโดยรอบ รับส่ง พาข้อมูล ตามช่วงเวลาที่คาดการณ์นัดหมายไว้กับ DTN Gateway 6

หน้าที่สำคัญของ DTN Gateway คือ

  • ทำหน้าที่ประสานงานให้ Region ใดบ้างก็ตาม ต้องทราบถึงชุด Protocol (Underlying Protocol), Propragration Delay Time, ฯ ของ Region นั้น
  • จัดเก็บ “Message – Bundle” ไว้ใน Nonvolatile Storage เผื่อเรียกเพื่อแก้ไขหากสุญหาย
  • Mapping ชื่ออ้างอิง Globally – Locally
  • ตรวจสอบ Access Control & Authentication

Name Tuples

ชื่อที่ใช้อ้างอิงเพื่อ Route เส้นทาง DTN Message สมควรจะประกอบไปด้วย 2 ส่วนคือ {Region Name, Entity Name}

Region Name

  • มีความเป็นหนึ่งเดียว ตลอดทั่วทั้ง DTN และมีการเชื่อมโยงแบบเป็น Hierarchically Structure,
  • มี DTN Gateway ทำหน้าที่ Route หา Region ปลายทางโดยไม่จำเป็นต้องแปลงจาก “Address String” ไปเป็นหมายเลขใดใดเลย
  • Region Name String มีความยืดหยุ่นเพื่อ Scalability ของระบบ
  • สิ่งที่ต้องคำนึง: “DTN Gateway” , “DTN Forwarding Table” , [Static, Dynamic] DTN Routing Protocol

Entity Name

  • ไว้ใช้อ้างอิง, รู้จัก, เฉพาะใน Region .. ณ. Region อื่นอาจซ้ำซ้อนได้
  • กระบวนการ Resolve Address เกิดขึ้นภายใน Region
  • DTN Gateway ทำการ “Late Binding” คือ Resolve Addr ที่ใช้อ้างถึงตามแต่ Region .. ตามแต่ชนิด Network เช่น IP สำหรับ Internet Region .. กระบวนการดังกล่าวต่างจาก DNS ที่แปลงจาก “URL” -> IP Addr ก่อนทำการส่งจาก End-node
  • Entity Name String มีความยืดหยุ่น …. เพราะอะไร ?

A Postal Class of Service

เลียนแบบการทำงานจากระบบไปรษณีย์ ที่รับส่งแบบ Non-Interactive Traffic โดยแบ่งการให้บริการออกเป็น Class ซึ่งแตกต่างกันที่กรรมวิธี Delivery เช่น การรับส่งที่ต้องการความปลอดภัย, ต้องการความสะดวกรวดเร็ว, หรือต้องการการรับประกันยืนยัน เป็นต้น

Path Selection & Scheduling

DTN Architecture มุ่งสนใจที่ Network Communication ที่คาดการณ์การมีอยู่ของ End-to-End Path ไม่ได้เสมอไป โดยระหว่างเส้นทางนั้น ประกอบด้วย “Contact” จุด-ต่อ-จุด ที่มี Parameter เช่น Start & End Time (ที่เปรียบเทียบกับ Source), Capacity, Latency, End Points, และ Direction เป็นต้น

คำถามคือ “การมีอยู่” ของเส้นทางนั้นสามารถคาดการณ์ได้หรือไม่ .. คาดการณ์ได้ เช่น Wired – ถาวร หรือ Satellite – Schedule .. คาดการณ์ไม่ได้ เช่น MANET – การสื่อสารใน AdHoc Wireless Node ที่เคลื่อนที่ .. และอีกประเด็นหนึ่ง คำว่าคาดการณ์ได้นั้นขึ้นกับทิศทาง, “Direction”, เช่นหากเป็นคนโทรไป ย่อมคาดการณ์ได้ .. แต่สำหรับผู้รับ จะคาดการณ์ไม่ได้

อย่างไรก็ดีในแต่ละ Region จะมี Routing Protocol ภายใน Region นั้นอยู่แล้ว จึงเหลือเป็นคำถามให้วิจัยต่อไป

“สามารถคาดการณ์, ยืนยัน, ถึงการมีอยู่ของ Contact ได้อย่างไร ?”

“การประเมิน Message ว่าสามารถ Delay ได้นานถึงระดับใด, Message’s Lifetime ?”

“การรับส่ง Message อย่างมีประสิทธิภาพ, Quality of Service (QoS) ?”

Custody Transfer & Reliability

Node, Message Router ใน DTN Architecture สามารถเป็นได้ 2 ชนิด .. Persistent (P) – มีการ Store Message เอาไว้บน Node .. Non-Persistent (NP) – ไม่มีการ Store Message .. ซึ่ง P Node และ Protocol ภายใน Region นั้น ทำงานร่วมกันในกระบวนการ “Custody Transfer”

“Custody Transfer” คือกระบวนการที่ Hop ที่ส่งข้อมูลรอรับ Acknowledgement จาก Hop ที่ส่งไป .. และหาก Hop ได้รับข้อมูล, จะ Response ยืนยันการได้รับข้อมูลแล้วจาก Hop ที่ส่งข้อมูลมา

  • ทั้งหมดเพื่อ Reliability
  • เป็นขั้นตอนที่จะมีผู้แทน, “Delegater”, มารับผิดชอบกระบวนการ Delivery เป็นทอด, Hop
  • ช่วยเหลือกรณีที่ข้อมูลมีโอกาสสูญหายสูง, End-node ไม่มี Resource (Energy, Memory) พอจะ Storage
  • ลด Acknowledgement แบบ End-to-End, ลด Latency ระหว่าง Negotiator
  • เชื่อว่าการเปลี่ยนจาก End-to-End Reliability Delivery ไปเป็น Hop-by-Hop Reliability Delivery จะไม่สร้างความแตกต่างเพราะเป็นการใช้ตัวแทน ทำหน้าที่ Acknowledge ระหว่างทาง, แทน End-node ซึ่งมีบางช่วงขณะที่ไม่สามารถมีอยู่ได้ตลอดเวลา
  • อาจใช้ทั้ง End-to-End และ Hop-by-Hop Acknowledgement ควบคู่กัน ตามแต่ Application กำหนด

Convergence Layers & Retransmission

สิ่งสำคัญคือ “เครื่องมือ อำนวยความสะดวก, ความสามารถ” ที่ Transport Protocol ของ DTN P Node ได้เตรียมไว้ให้ .. ความสามารถ อาทิเช่น Reliability Delivery, Connections ที่รายงาน Failure ได้, Flow Control, Congestion Control, และ Message Boundaries เป็นต้น

  • ในกรณีที่ “Reliability Delivery” ถูกจัดการโดย Transport Layer ที่มีอยู่แล้ว .. Convergence Layer เพียงแต่คอยตรวจสอบ State ของ Connection และ Re-initial Connection หากขาด
  • ในกรณี “Connection-Oriented Protocol” การตรวจสอบการขาดของ Connection จะรายงานตรงต่อ Application ผ่าน API (Socket API)
  • ในกรณีที่ไม่มี API Support โดยตรงเพื่อตรวจสอบ Failure, Bundle Forwarding Function จำเป็นต้องอาศัยการจับเวลาเพื่อตัดสินใจที่จะจัดการ Connection นั้น ซึ่งจะแตกต่างกันไปตามแต่ชั้น “Physical Layer” ที่อยู่ด้านล่าง
  • หน้าที่อีกอย่างหนึ่งของ Convergence Layer รายงาน Path Properties แก่ DTN Application

“ปัจจุบันการออกแบบ Convergence Layer สำหรับ Network Scenario ต่างๆ ยังคงเป็นหัวข้อวิจัย”

Time Synchronization

DTN Architecture ต้องการฐานเวลาโดยละเอียดเพื่อตัดสินใจที่จะทิ้ง, “Purge”, Message ที่หมดอายุตาม Lifetime ที่ได้กำหนดจากต้นทาง, ต้องการใช้เวลาเพื่อกำหนด Scheduling การเลือกเส้นทาง

“จะทำอย่างไร ให้ Node มีเวลาที่ Accuracy – แม่นยำ ? .. หมายถึง เวลานั้นอาจไม่เท่ากัน แต่เหลื่อมกันแบบคงที่เสมอ”

“เวลาคาดเคลื่อนที่แน่นอน ? .. จะควบคุม Congestion ใน Network ได้อย่างไร ? .. ส่งผลถึง Precision และ Accuracy ของเวลา”

“NTP to Space กำลังวิจัยกันอยู่”

Security

Congestion & Flow Control

ใน Hop-by-Hop Architecture, Flow Control และ Congestion Control สำหรับ DTN นั้นใกล้เคียงกัน ในที่นี้ สำหรับ Flow Control จำกัดอัตราการส่งของ DTN Node ระหว่างกัน

สำหรับ Congestion Control จะดูประเด็นเรื่องการแย่งชิงกันใช้พื้นที่หน่วยความจำถาวร , Persistent Storage, ใน DTN Gateway โดยมีกลไก, Mechanism, ที่จะช่วยแก้ปัญหาข้างต้นแบ่งออกเป็นสองพวก .. Proactive = เกี่ยวข้องกับการควบคุมการ Admission เพื่อแก้ไข Congestion ตั้งแต่เริ่มแรก เช่นว่า DTN Gateway ให้โอกาส End-node ให้เข้ามาใช้งานได้ครั้งละหนึ่งเท่านั้น .. Reactive = อาศัยการ Delay เพื่อลดการ Congestion เช่น การเพิ่มเวลาที่ใช้ในแต่ละกระบวนการที่ End-node ติดต่อ DTN Gateway (จะเกี่ยวข้องกับการควบคุม Flow Control)

Constraint ใน DTN ที่เป็นประเด็น

“Contacts may not arrive for some time in the future (so accumulated data may not have an opportunity to drain for some time).”
บางครั้งอาจจะไม่มีการติดต่อมาอีกในอนาคต ทำให้ไม่มี Message ส่วนที่เหลือ ต่อจากส่วนที่ได้รับมาแล้วตามมาอีก

“Received messages for which custody has been accepted cannot be discarded except under extreme circumstances or on expiration.”
Message ที่ได้รับแล้วบางส่วนต้องถูกเก็บไว้ เว้นเสียแต่ในบางสถานการณ์ หรือหมดอายุ

จากข้อจำกัดข้างต้น เสนอกรรมวิธีจัดการกับ Congestion เช่น การจอง Buffer Space สำหรับทำ QoS, ปฏิเสธการเชื่อมต่อขอบริการอื่นที่เข้ามาใหม่เมื่อ Buffer เต็ม, จัดเรียงการรับส่งแบบ Custody Transfer ไปให้กับ Hop ที่ยังมีศักยภาพรับผิดชอบได้ ถึงแม้ไม่ใช่ Next Hop ที่น่าจะถูกเลือกมากที่สุด (Hot Potato Routing), และละทิ้ง Non-custody Message เพื่อใช้ความสามารถกับ Custody Message เป็นต้น

วิธีการที่ใช้กันอยู่ปัจจุบันคือ Shared Priority Queue สำหรับจัดการเนื้อที่บันทึก Custody Message นั่นคือ ขั้นแรก Message ที่หมดอายุต้องถูกกำจัด, สำหรับ Message ที่ขนาดใหญ่เกินจะถูกปฏิเสธ .. ต่อมา Message นั้นถูกจัดเก็บบนพื้นฐานของ “Priority” และ “Lifetime” (กำหนดโดยผู้ส่ง) .. ก่อให้เกิดปัญหาที่ตามมาคือ เรื่องของ Priority Inversion (Message Priority ต่ำกว่า แต่มาก่อนได้รับการเก็บ Storage จนไม่เหลือเนื้อที่ให้กับ Message Priority สูงกว่า ที่ตามมา) และ Head-of-Line Blocking (เมื่อ Gateway ทำการ Custody Message ไว้แล้ว แต่ปลายทางยังไม่ Available สักที .. ทำให้ Custody Message เพิ่มขึ้นเรื่อยๆ .. สุดท้าย Message อื่นๆที่ตามมาก็ถูก Block อยู่ใน Queue)

สำหรับการ Implement Flow Control ใน DTN Forwarder สามารถทำได้วิธีหนึ่งคือ อาศัยกลไกที่มีอยู่ตามแต่ละ Region-Local Network เช่น TCP, X.25, XON/XOFF, CTS/RTS, Admission Rate Control, etc. .. ซึ่งคือกลไก Hand Shaking ของ Link หรือใน Transport Protocol เอง .. ส่วนอีกวิธีที่ทำได้คือ สร้างกลไกขึ้นใน DTN Forwarder ในชั้น Convergence Layer เพื่อทำงานคล้างกับ Traffic Shapers

Note

  • End-node ต้นทางจะทราบได้อย่างไรว่า จะต้องส่งข้อมูลให้กับ DTN Gateway ตัวใด ?
  • Name Tuples มีความยืดหยุ่น เพราะอะไร ? … ต้องนิยามโครงสร้างแบบไหน ?
  • การสร้าง Application Interface (Overlay ทำหน้าที่แลกเปลื่ยนข้อมูล) ต้องระวังเรื่อง Response Time และ Turn-around Time ไม่ให้เกินกำหนดที่ Client/Server จะมีอายุอยู่ได้ => Persist Storage, Bandwidth เปล่า … อีกคุณสมบัติหนึ่งคือ Scalability ให้สามารถเพิ่มเติมรับรู้ Region, End-node ใหม่ได้ รวมถึงสามารถกำหนด Class การให้บริการ, ทำ Authentication ได้
  • งานที่เกี่ยวข้องเช่น Interplanetary Internet, ZebraNet, Data MULEs
Advertisements
มาตรฐาน

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s