1 / 42

NS2_Trace and Monitoring support 報告者 : 羅士捷

NS2_Trace and Monitoring support 報告者 : 羅士捷. Outline. Trace Support ‧OTcl Helper Functions Library support and examples The C++ Trace Class Trace File Format. Trace Support. Traces => Record each individual packet as it arrives, departs, or is dropped at a link or queue.

hans
Download Presentation

NS2_Trace and Monitoring support 報告者 : 羅士捷

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. NS2_Trace and Monitoring support 報告者:羅士捷

  2. Outline • Trace Support ‧OTcl Helper Functions • Library support and examples • The C++ Trace Class • Trace File Format

  3. Trace Support • Traces => Record each individual packet as it arrives, departs, or is dropped at a link or queue. • Trace data is either displayed directly during execution of the simulation, or (more commonly) stored in a file to be post-processed and analyzed.

  4. Trace Support • The trace support in OTcl consists of a number of specialized classes visible in OTcl but implemented in C++ => Combined with a set of Tcl helper procedures and classes defined in the library. Trace/Hop: trace a hop Trace/Enque: packet arrival Trace/Deque: packet departure Trace/Drop: packet drop Trace/Recvpacket: receive event at the destination node of a link

  5. 加入Trace對象

  6. OTcl Helper Functions • The following helper functions may be used within simulation scripts to help in attaching trace elements (they are instance procedures of the class Simulator). $ns_ flush-trace This command flushes the trace buffer. $ns_ create-trace type file srcdst This command creates a trace object of type <type> between the <src> and <dst> nodes. The traces are written into the <file>.

  7. OTcl Helper Functions $ns_ trace-queue n1 n2 optional:file This command creates a trace object for tracing events on the link represented by the nodes <n1> and <n2>. $ns_ drop-trace n1 n2 trace This command makes the given <trace> object a drop- target for the queue associated with the link between nodes <n1> and <n2>.

  8. Library support and examples • The Simulator procedures described above require the trace and init-monitor methods associated with the OTcl Link class. • Several subclasses of link are defined, the most common of which is called SimpleLink. Thus, the trace and init-monitor methods are actually part of the SimpleLink class rather than the Link base class. • The trace function is defined as follows (in ns-link.tcl):

  9. Library support and examples

  10. Library support and examples • This function establishes Enque, Deque, and Drop traces in the simulator $ns and directs their output to I/O handle $f. The function assumes a queue has been associated with the link. It operates by first creating three new trace objects and inserting the Enque object before the queue, the Deque object after the queue, and the Drop object between the queue and its previous drop target. Note that all trace output is directed to the same I/O handle.

  11. The C++ Trace Class • The single C++ Trace class is used to implement the OTcl classes Trace/Hop, Trace/Enque, Trace/Deque, and Trace/Drop. • The type _ field is used to differentiate among the various types of traces any particular Trace object might implement. Currently, this field may contain one of the following symbolic characters: => + for enque,-for deque, h for hop, and d for drop.

  12. The C++ Trace Class • The overall class is defined as follows in trace.cc:

  13. Trace File Format • The []Trace::format method defines the trace file format used in trace files produced by the Trace class. • It formats the source, destination, and type fields defined in the trace object (not in the packet headers), the current time, along with various packet header fields including, type of packet (as a name), size, flags (symbolically), flow identifier, source and destination packet header fields, sequence number (if present), and unique identifier.

  14. Trace File Format

  15. Trace File Format • An example of a trace file (without the tcp header fields) might appear as follows:

  16. NS2_Packet headers and format

  17. Outline • Introduction • An Overview of Packet Modeling Principle • Packet Header • An Overview of First Level Packet Composition • Protocol Specific Headers • Packet Header Access Mechanism • Packet Header Manager • Customizing Packets Step by Step

  18. Introduction • Packet consists of packet header and data payload. • In most cases, NS2 extracts information from data payload and stores theinformation into packet header(This idea removes the need to process data payload at runtime; e.g. NS2 stores packet size in variable hdr_cmn::size_). • This chapter discusses how NS2 models packets.

  19. An Overview of Packet Modeling Principle(1/6)

  20. An Overview of Packet Modeling Principle(2/6) • Actual Packet: An actual packet refers to the portion of memory whichstores packet header and data payload. (NS2 does not directly access either the packet header or the data payload. Rather, it uses pointers bits_ and data_ of class Packet to access packet header and data payload, respectively.) • Class Packet: Declared in Program 8.1, class Packet is the C++ main class which represents packets. It contains the following variables and functions:

  21. An Overview of Packet Modeling Principle(3/6) • Protocol Specific Header: A protocol specific header stores packet attributes relevant to the underlying protocol only.(common packet header: packet unique ID, packet size, packet type; IP packet header: source and destination IP Addresses, port numbers) • For each protocol specific header: C++ class, OTcl class, mapping class. • Packet Header Manager: Responsible for keeping the list of active protocols and setting the offset values of all the active protocols.

  22. An Overview of Packet Modeling Principle(4/6)

  23. An Overview of Packet Modeling Principle(5/6) • C++ variables of class Packet

  24. An Overview of Packet Modeling Principle(6/6) • C++ functions of class Packet

  25. Packet Header(1/2) • As a part of a packet, packet header contains packet attributes such as packet unique ID, and IP address. • On the first level,NS2 puts together all relevant protocol specific headers (e.g., common header, IP header, TCP header) and composes a packet header.(The location of each protocol specific header on bits_ is identified by its variable offset_.) • The second level imposes a packet attribute storing structure on each protocol specific header.(packet attributes are stored as members of a C++ struct data type) • In practice, a packet contains only relevant protocol specific headers.(Activate/Deactivate a Protocol Specific Header)

  26. Packet Header(2/2) The distance between the beginning of packet header and that of a protocol specific header two-level structure

  27. An Overview of First Level Packet Composition(1/2) • Common Packet Header • Containing packet attributes which are common to all packets. It employs C++ struct data type hdr_cmn to indicate how the packet attributes are stored. • IP Packet Header • Represented by C++ struct data type hdr_ip, IP packet header contains information about source and destination of a packet.

  28. An Overview of First Level Packet Composition(2/2)

  29. Protocol Specific Headers(1/2) • Each protocol specific header involves three classes. • A Protocol Specific Header C++ Class • NS2 uses a struct data type to represent a protocol specific header. • It stores packet attributes and its offset value in members of a struct data type. • It also provides a function access(p) which returns the reference to the protocol specific header of a packet *p. • C++ class name for common packet header is hdr_cmn.

  30. Protocol Specific Headers(2/2) • A Protocol Specific Header OTcl Class • NS2 defines a shadow OTcl class for each C++ protocol specific header class. • An OTcl class acts as an interface to the OTcl domain. • the OTcl class name for common packet header is PacketHeader/Common. • A Protocol Specific Header Mapping Class • responsible for binding OTcl and C++ class names together. • All the packet header mapping classes derive from class PacketHeaderClass which is a child class of class TclClass. • the mapping class name for common packet header is CommonHeaderClass.

  31. Packet Header Access Mechanism(1/3) • How packet attributes stored in packet header can be retrieved and modified? • NS2 employs a two-level packet header structure to store packet attributes. • On the first level, protocol specific headers are stored within a packet header. • On the second level, each protocol specific header employs a C++ struct data type to store packet attributes.

  32. Packet Header Access Mechanism(2/3)

  33. Packet Header Access Mechanism(3/3)

  34. Packet Header Manager(1/2) • Responsible for keeping the list of active protocols and setting the offset values of all the active protocols. • It is implemented using a C++ class PacketHeaderManager which is bound to an OTcl class with the same name.

  35. Packet Header Manager(2/2)

  36. Customizing Packets(1/6) • Defining a New Packet Header • When designing a new protocol, a user may need to change the packet format. • Suppose we would like to include a new protocol specific header, namely “My Header”, into the packet header. • We need to define a C++ class (e.g.,hdr_myhdr), an OTcl class (e.g., PacketHeader/MyHeader), and a mapping class (e.g., MyHeaderClass) for My Header, and include the OTcl class into the active protocol list.

  37. Customizing Packets(2/6) Step by Step • Step 1: Define a protocol specific header C++ struct hdr_myhdr (e.g.,see Program 8.6). • Declare variable offset_. • Define function access(p) (see Lines 8–10 in Program 8.6). • Include all member variables required to hold new packet attributes.

  38. Customizing Packets(3/6) • Step 2: Define a protocol specific header OTcl class PacketHeader/MyHeader. • Step 3: Derive a mapping class MyHeaderClass from class PacketHeader Class (e.g, see class CommonHeaderClass in Program 8.12). • At the construction, feed the corresponding OTcl class name (i.e.,PacketHeader/MyHeader) and the size needed to hold the protocol specific header (i.e., sizeof(hdr_myhdr)) to the constructor of class PacketHeaderClass (e.g., see Line 3 in Program 8.12).

  39. Customizing Packets(4/6)

  40. Customizing Packets(5/6) • From within the constructor, invoke function bind_offset(...) feeding the address of the variable offset_ of the C++ struct data type as an input argument. (i.e., invoke bind_offset(&hdr_myhdr::offset_)). • Instantiate a mapping variable class_myhdr at the declaration. • Step 4: Activate My Header by including class PacketHeader/MyHeader into the active protocol list.(modify Program 8.15 )

  41. Customizing Packets(6/6) 加入 MyHeader

More Related