一個有經驗的 Developer 對於剛接手的已存在的只有程式碼軟體開發專案，要能 了解這個軟體的架構是什麼至少要花數個小時，如果這個軟體專案有 Model Diagram，則這個 Developer 則很快就可以了解這個軟體架構。

一般而言 Diagramming Language 都應該提供下列資訊：

　‧Overall architecture of the system 　‧System dependencies 　‧Complexity 　‧Flow of information through a system 　‧Business requirements 　‧Database organization and structure 　‧Source code – including almost every aspect of object-oriented development 　‧Deployment configurations

一個軟體專案如果有使用 Visual Models，我們就能從比較高的層次去看這個 Project， 藉由從較高層次圖去找尋 Fine-Grained Diagram。 這樣的方法可以幫助 Architect 和 Engineer 直覺地 (Intuitively) 掌握住問題並解決它， 軟體問題容易掌握 ，時間自然縮短，品質自然提高。

18th. Part: NetworkLayer6.ned: disable OSPF, RSVP 原 protocolMapping = "6:0,17:1,1:2,2:3,46:4,89:5"; 表示 TCP (6):0, UDP (17):1, ICMP (1):2, IGMP (2):3, RSVP (46):4, OSPF (89):5 考慮到保證將來 DualStack 相容性，因此不更改原對應數字，而從後面再繼續補加.

暫時補加 ICMPv6 (58):2, ROUTING (43), MOBILITY (135) protocolMapping 後添上 58:6,43:7,135:8

• 應再找資料確認 Neighbor Discovery -- ND 模組是否應包含在 ICMPv6 模組裡

19th. Part: 照著 Winodws 步驟，以 TicToc10 為基礎編譯. OMNET++/Sample/INET6Test: 修改 IP6Datagram.msg 以通過 compiler.

這次是針對 "模擬" 來做修正:

• 因為 20 bits 不好宣告 (RFC 中是連 version, Traffic Class 一同宣告在一起), 因此 flow label 欄位訂的較 RFC 小 (20->16) (反正沒在用，應該沒什麼關係)
• 在訂 IPv6 options message struct 時，Padding 不加似乎也沒關係
• IP6FRAGMENT identification 欄位訂的較 RFC 小 (32->16)

目前採用方式 -> 全改用 int , short, long 來宣告，皆遠大於所需位元數

Review: Global Dynamic Home Agent Discovery on Mobile IPv6 Q1. 訊息流程一不一樣？ Ay: -> 原不需用 RR An: -> 模擬該重做

外: Paper 檢查注意:

• 規格: A4, 上下 30mm, 左右 20mm, 中間 8mm, 左右對齊。字高 10pt. 圖片引用次序 參考引用次序 內: Problem solving:

1. Setup sample space2. Define probability law3. Identify event of interest4. Calculate... 原則:

• 先討論做某件事的老方法，

• 再和新解決方法建立關聯.

• 提案前先確定它有效，成功 提綱:

• 要有完整的 survey, 也就是完整的 view

• 針對某些很明確的問題來想出正確可靠的解決辦法，細節要想透及交待清楚

      1.  想解決什麼樣的問題
  2.  清楚地告訴大家有人是如何解決
  3.  想解決問題的完整步驟是什麼*   完整解決問題的方法及步驟
  

  http://www.icce.org/authors_page/Summary%20Guide.htm

1. Outline: An author's contribution is of value to the reader only if the information is presented in a clear and well-organized way. Papers and summaries that follow an outline similar to that below are likely to provide readers with the best information as to their value.
2. Introduction. This section should provide the motivation for the paper. Why is this an interesting and important topic to which the reader should allocate time and effort? How does it differ from prior art? A brief description of the research and development process, and the results, should follow.
3. Review and overview. The author should describe the present state of knowledge and, if appropriate, provide references. This should lead to an overview of the new direction taken.
4. Development method/procedures. The methods and reasons for the design choices should be described in sufficient detail for readers to be able to judge the validity, reliability and general applicability of the results.
5. Results. Important results should be well summarized. More complete experimental results are expected in a paper than space allows in a summary. The results should be directly related to the topics presented in the introduction and in the overview of the new direction taken.
6. Conclusion. The final section should highlight the author's contribution. That is, what do we now know that we did not know before this paper was presented? It should also mention limitations of the work and provide suggestions for future improvement in this area.
7. References. A good paper lists references that support key statements and assumptions.

新 r 33.908773621 3 MAC --- 334 mipv6_bu 70 [13a 1 4 800] ------- [4196353:0 0:0 32 4198400] 舊 s -t 1.000075000 -Hs 22 -Hd 2147483647 -Ni 22 -Nx 100.00 -Ny 2200.00 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw --- -Ma 0 -Md ffffffff -Ms 14 -Mt 800 -Is 4222977.0 -Id 2147483647.0 -It ipv6_sol -Il 100 -If 0 -Ii 1 -Iv 255

欄位: event type 事件類型)

有四種基本事件類型

• s: send (傳送)
• r: receive (接收)
• d:drop (丟棄)
• f: forward (轉送)

還有一種特別類型

• m: move (移動)

欄位 2: general flag

-t: time (時間)

欄位 3: Next hop info (下一站的資訊)

-Hs: id for this node -Hd: id for next hop towards the destination

欄位 4: Node property type tag (節點屬性類型標籤

-Ni: node id (節點 ID) -Nx –Ny -Nz: node s x/y/z coordinate (節點 x/y/z 的座標位置) -Ne: node energy level -Nl: trace level, such as AGT, RTR, MAC -Nw: reason for the event (事件發生原因)

欄位 5: packet info at MAC level (封包在 Mac 層的資訊)

-Ma: duration -Md: dest’s ethernet address -Ms: src’s ethernet address -Mt: ethernet type

欄位 6: Packet information at IP level (封包在 IP 層的資訊)

-Is: source address. Source port number (來源位置，a.b 其中 a 為節點 ID, b 為埠號 -Id: dest address.dest port number (目的位置) -It: packet type (封包類型) -Il: packet size (封包大小) -If: flow id (資料流 ID) -Ii: unique id (唯一的 ID 編號) -Iv: ttl value (Time To Live 的值)

欄位 7: 封包在應用層的資訊。

包含的應用程式類型如 arp, tcp 或者是 adhoc 路由協定，這個欄位都是以 P 所開頭的， 且標籤為隨著應用程式不同而不同

Trace 檔分析:

Packet Loss 數量計算: 不考慮 Out-of-Order 情況時，Packet Loss 數量的計算方法最簡單，每一個封包在傳送端發送前，傳送端都會給封包一個序號，序號是連續性的，因此若是在接收到發現序號有不連續的發生，則可視為有封包的移失。

OWD&IPDV 計算: 最重要的欄位是 Sending Time (傳送時間) 和 Sequence Number (封包序號), 可以用來計算出 One Way Delay (OWD) 和 IP Delay Variance (IPDV，或是 Jitter)。

One Way Delay = 接收時間 – 傳送時間

IPDV = | 目前量測到的 OWD - 上一次量測到的 OWD|

Reference:​

http://140.116.72.80/~smallko/ns2/wireless1.htm http://www.k-lug.org/~griswold/NS2/ns2-trace-formats.html http://www.ee.surrey.ac.uk/Personal/L.Wood/ns/

17th Part:

檔案管理方式決定: 用 freemind 畫好了 INET6 與 INET 檔案分佈圖， 隨時比較兩者間相應模組與進度

封包測試方式決定: 使用 tictoc scenario 先測試 IPv6, ICMPv6 封包格式的正確性