Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5102

Information Model for IP Flow Information Export

Pages: 171
Obsoleted by:  7012
Updated by:  6313
Part 4 of 7 – Pages 67 to 87
First   Prev   Next

ToP   noToC   RFC5102 - Page 67   prevText

5.9. Flow Timestamps

Information Elements in this section are timestamps of events. Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds, flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds, flowStartNanoseconds, flowEndNanoseconds, and systemInitTimeMilliseconds are absolute and have a well-defined fixed time base, such as, for example, the number of seconds since 0000 UTC Jan 1st 1970. Timestamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds are relative timestamps only valid within the scope of a single IPFIX Message. They contain the negative time offsets relative to the export time specified in the IPFIX Message Header. The maximum time offset that can be encoded by these delta counters is 1 hour, 11 minutes, and 34.967295 seconds. Timestamps flowStartSysUpTime and flowEndSysUpTime are relative timestamps indicating the time relative to the last (re- )initialization of the IPFIX Device. For reporting the time of the last (re-)initialization, systemInitTimeMilliseconds can be reported, for example, in Data Records defined by Option Templates. +-----+---------------------------+-----+---------------------------+ | ID | Name | ID | Name | +-----+---------------------------+-----+---------------------------+ | 150 | flowStartSeconds | 156 | flowStartNanoseconds | | 151 | flowEndSeconds | 157 | flowEndNanoseconds | | 152 | flowStartMilliseconds | 158 | flowStartDeltaMicroseconds| | 153 | flowEndMilliseconds | 159 | flowEndDeltaMicroseconds | | 154 | flowStartMicroseconds | 160 | systemInitTimeMilliseconds| | 155 | flowEndMicroseconds | 22 | flowStartSysUpTime | | | | 21 | flowEndSysUpTime | +-----+---------------------------+-----+---------------------------+

5.9.1. flowStartSeconds

Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeSeconds ElementId: 150 Status: current Units: seconds
ToP   noToC   RFC5102 - Page 68

5.9.2. flowEndSeconds

Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeSeconds ElementId: 151 Status: current Units: seconds

5.9.3. flowStartMilliseconds

Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeMilliseconds ElementId: 152 Status: current Units: milliseconds

5.9.4. flowEndMilliseconds

Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeMilliseconds ElementId: 153 Status: current Units: milliseconds

5.9.5. flowStartMicroseconds

Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeMicroseconds ElementId: 154 Status: current Units: microseconds

5.9.6. flowEndMicroseconds

Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeMicroseconds ElementId: 155 Status: current Units: microseconds
ToP   noToC   RFC5102 - Page 69

5.9.7. flowStartNanoseconds

Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeNanoseconds ElementId: 156 Status: current Units: nanoseconds

5.9.8. flowEndNanoseconds

Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeNanoseconds ElementId: 157 Status: current Units: nanoseconds

5.9.9. flowStartDeltaMicroseconds

Description: This is a relative timestamp only valid within the scope of a single IPFIX Message. It contains the negative time offset of the first observed packet of this Flow relative to the export time specified in the IPFIX Message Header. Abstract Data Type: unsigned32 ElementId: 158 Status: current Units: microseconds Reference: See the IPFIX protocol specification [RFC5101] for the definition of the IPFIX Message Header.

5.9.10. flowEndDeltaMicroseconds

Description: This is a relative timestamp only valid within the scope of a single IPFIX Message. It contains the negative time offset of the last observed packet of this Flow relative to the export time specified in the IPFIX Message Header. Abstract Data Type: unsigned32 ElementId: 159 Status: current Units: microseconds Reference: See the IPFIX protocol specification [RFC5101] for the definition of the IPFIX Message Header.
ToP   noToC   RFC5102 - Page 70

5.9.11. systemInitTimeMilliseconds

Description: The absolute timestamp of the last (re-)initialization of the IPFIX Device. Abstract Data Type: dateTimeMilliseconds ElementId: 160 Status: current Units: milliseconds

5.9.12. flowStartSysUpTime

Description: The relative timestamp of the first packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). Abstract Data Type: unsigned32 ElementId: 22 Status: current Units: milliseconds

5.9.13. flowEndSysUpTime

Description: The relative timestamp of the last packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). Abstract Data Type: unsigned32 ElementId: 21 Status: current Units: milliseconds

5.10. Per-Flow Counters

Information Elements in this section are counters all having integer values. Their values may change for every report they are used in. They cannot serve as part of a Flow Key used for mapping packets to Flows. However, potentially they can be used for selecting exported Flows, for example, by only exporting Flows with more than a threshold number of observed octets. There are running counters and delta counters. Delta counters are reset to zero each time their values are exported. Running counters continue counting independently of the Exporting Process. There are per-Flow counters and counters related to the Metering Process and/or the Exporting Process. Per-Flow counters are Flow properties that potentially change each time a packet belonging to
ToP   noToC   RFC5102 - Page 71
   the Flow is observed.  The set of per-Flow counters includes the
   Information Elements listed in the table below.  Counters related to
   the Metering Process and/or the Exporting Process are described in
   Section 5.3.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   |   1 | octetDeltaCount           | 134 | droppedOctetTotalCount    |
   |  23 | postOctetDeltaCount       | 135 | droppedPacketTotalCount   |
   | 198 | octetDeltaSumOfSquares    |  19 | postMCastPacketDeltaCount |
   |  85 | octetTotalCount           |  20 | postMCastOctetDeltaCount  |
   | 171 | postOctetTotalCount       | 174 | postMCastPacketTotalCount |
   | 199 | octetTotalSumOfSquares    | 175 | postMCastOctetTotalCount  |
   |   2 | packetDeltaCount          | 218 | tcpSynTotalCount          |
   |  24 | postPacketDeltaCount      | 219 | tcpFinTotalCount          |
   |  86 | packetTotalCount          | 220 | tcpRstTotalCount          |
   | 172 | postPacketTotalCount      | 221 | tcpPshTotalCount          |
   | 132 | droppedOctetDeltaCount    | 222 | tcpAckTotalCount          |
   | 133 | droppedPacketDeltaCount   | 223 | tcpUrgTotalCount          |
   +-----+---------------------------+-----+---------------------------+

5.10.1. octetDeltaCount

Description: The number of octets since the previous report (if any) in incoming packets for this Flow at the Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 1 Status: current Units: octets

5.10.2. postOctetDeltaCount

Description: The definition of this Information Element is identical to the definition of Information Element 'octetDeltaCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 23 Status: current Units: octets
ToP   noToC   RFC5102 - Page 72

5.10.3. octetDeltaSumOfSquares

Description: The sum of the squared numbers of octets per incoming packet since the previous report (if any) for this Flow at the Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 ElementId: 198 Status: current

5.10.4. octetTotalCount

Description: The total number of octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 85 Status: current Units: octets

5.10.5. postOctetTotalCount

Description: The definition of this Information Element is identical to the definition of Information Element 'octetTotalCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 171 Status: current Units: octets

5.10.6. octetTotalSumOfSquares

Description: The total sum of the squared numbers of octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 ElementId: 199 Status: current Units: octets
ToP   noToC   RFC5102 - Page 73

5.10.7. packetDeltaCount

Description: The number of incoming packets since the previous report (if any) for this Flow at the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 2 Status: current Units: packets

5.10.8. postPacketDeltaCount

Description: The definition of this Information Element is identical to the definition of Information Element 'packetDeltaCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 24 Status: current Units: packets

5.10.9. packetTotalCount

Description: The total number of incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 86 Status: current Units: packets
ToP   noToC   RFC5102 - Page 74

5.10.10. postPacketTotalCount

Description: The definition of this Information Element is identical to the definition of Information Element 'packetTotalCount', except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 172 Status: current Units: packets

5.10.11. droppedOctetDeltaCount

Description: The number of octets since the previous report (if any) in packets of this Flow dropped by packet treatment. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 132 Status: current Units: octets

5.10.12. droppedPacketDeltaCount

Description: The number of packets since the previous report (if any) of this Flow dropped by packet treatment. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 133 Status: current Units: packets

5.10.13. droppedOctetTotalCount

Description: The total number of octets in packets of this Flow dropped by packet treatment since the Metering Process (re-)initialization for this Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 134 Status: current Units: octets
ToP   noToC   RFC5102 - Page 75

5.10.14. droppedPacketTotalCount

Description: The number of packets of this Flow dropped by packet treatment since the Metering Process (re-)initialization for this Observation Point. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 135 Status: current Units: packets

5.10.15. postMCastPacketDeltaCount

Description: The number of outgoing multicast packets since the previous report (if any) sent for packets of this Flow by a multicast daemon within the Observation Domain. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 19 Status: current Units: packets

5.10.16. postMCastOctetDeltaCount

Description: The number of octets since the previous report (if any) in outgoing multicast packets sent for packets of this Flow by a multicast daemon within the Observation Domain. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 20 Status: current Units: octets
ToP   noToC   RFC5102 - Page 76

5.10.17. postMCastPacketTotalCount

Description: The total number of outgoing multicast packets sent for packets of this Flow by a multicast daemon within the Observation Domain since the Metering Process (re-)initialization. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 174 Status: current Units: packets

5.10.18. postMCastOctetTotalCount

Description: The total number of octets in outgoing multicast packets sent for packets of this Flow by a multicast daemon in the Observation Domain since the Metering Process (re-)initialization. This property cannot necessarily be observed at the Observation Point, but may be retrieved by other means. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 175 Status: current Units: octets

5.10.19. tcpSynTotalCount

Description: The total number of packets of this Flow with TCP "Synchronize sequence numbers" (SYN) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 218 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP SYN flag.
ToP   noToC   RFC5102 - Page 77

5.10.20. tcpFinTotalCount

Description: The total number of packets of this Flow with TCP "No more data from sender" (FIN) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 219 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP FIN flag.

5.10.21. tcpRstTotalCount

Description: The total number of packets of this Flow with TCP "Reset the connection" (RST) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 220 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP RST flag.

5.10.22. tcpPshTotalCount

Description: The total number of packets of this Flow with TCP "Push Function" (PSH) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 221 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP PSH flag.
ToP   noToC   RFC5102 - Page 78

5.10.23. tcpAckTotalCount

Description: The total number of packets of this Flow with TCP "Acknowledgment field significant" (ACK) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 222 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP ACK flag.

5.10.24. tcpUrgTotalCount

Description: The total number of packets of this Flow with TCP "Urgent Pointer field significant" (URG) flag set. Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 223 Status: current Units: packets Reference: See RFC 793 for the definition of the TCP URG flag.

5.11. Miscellaneous Flow Properties

Information Elements in this section describe properties of Flows that are related to Flow start, Flow duration, and Flow termination, but they are not timestamps as the Information Elements in Section 5.9 are. +-----+---------------------------+-----+---------------------------+ | ID | Name | ID | Name | +-----+---------------------------+-----+---------------------------+ | 36 | flowActiveTimeout | 161 | flowDurationMilliseconds | | 37 | flowIdleTimeout | 162 | flowDurationMicroseconds | | 136 | flowEndReason | 61 | flowDirection | +-----+---------------------------+-----+---------------------------+
ToP   noToC   RFC5102 - Page 79

5.11.1. flowActiveTimeout

Description: The number of seconds after which an active Flow is timed out anyway, even if there is still a continuous flow of packets. Abstract Data Type: unsigned16 ElementId: 36 Status: current Units: seconds

5.11.2. flowIdleTimeout

Description: A Flow is considered to be timed out if no packets belonging to the Flow have been observed for the number of seconds specified by this field. Abstract Data Type: unsigned16 ElementId: 37 Status: current Units: seconds

5.11.3. flowEndReason

Description: The reason for Flow termination. The range of values includes the following: 0x01: idle timeout The Flow was terminated because it was considered to be idle. 0x02: active timeout The Flow was terminated for reporting purposes while it was still active, for example, after the maximum lifetime of unreported Flows was reached. 0x03: end of Flow detected The Flow was terminated because the Metering Process detected signals indicating the end of the Flow, for example, the TCP FIN flag. 0x04: forced end The Flow was terminated because of some external event, for example, a shutdown of the Metering Process initiated by a network management application.
ToP   noToC   RFC5102 - Page 80
      0x05: lack of resources
            The Flow was terminated because of lack of resources
            available to the Metering Process and/or the Exporting
            Process.

   Abstract Data Type: unsigned8
   Data Type Semantics: identifier
   ElementId: 136
   Status: current

5.11.4. flowDurationMilliseconds

Description: The difference in time between the first observed packet of this Flow and the last observed packet of this Flow. Abstract Data Type: unsigned32 ElementId: 161 Status: current Units: milliseconds

5.11.5. flowDurationMicroseconds

Description: The difference in time between the first observed packet of this Flow and the last observed packet of this Flow. Abstract Data Type: unsigned32 ElementId: 162 Status: current Units: microseconds

5.11.6. flowDirection

Description: The direction of the Flow observed at the Observation Point. There are only two values defined. 0x00: ingress flow 0x01: egress flow Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 61 Status: current

5.12. Padding

This section contains a single Information Element that can be used for padding of Flow Records.
ToP   noToC   RFC5102 - Page 81
   IPFIX implementations may wish to align Information Elements within
   Data Records or to align entire Data Records to 4-octet or 8-octet
   boundaries.  This can be achieved by including one or more
   paddingOctets Information Elements in a Data Record.

   +-----+---------------------------+-----+---------------------------+
   |  ID | Name                      |  ID | Name                      |
   +-----+---------------------------+-----+---------------------------+
   | 210 | paddingOctets             |     |                           |
   +-----+---------------------------+-----+---------------------------+

5.12.1. paddingOctets

Description: The value of this Information Element is always a sequence of 0x00 values. Abstract Data Type: octetArray ElementId: 210 Status: current

6. Extending the Information Model

A key requirement for IPFIX is to allow for extending the set of Information Elements that are reported. This section defines the mechanism for extending this set. Extension can be done by defining new Information Elements. Each new Information Element MUST be assigned a unique Information Element identifier as part of its definition. These unique Information Element identifiers are the connection between the record structure communicated by the protocol using Templates and a consuming application. For generally applicable Information Elements, using IETF and IANA mechanisms to extend the information model is RECOMMENDED. Names of new Information Elements SHOULD be chosen according to the naming conventions given in Section 2.3. For extensions, the type space defined in Section 3 can be used. If required, new abstract data types can be added. New abstract data types MUST be defined in IETF Standards Track documents. Enterprises may wish to define Information Elements without registering them with IANA. IPFIX explicitly supports enterprise-specific Information Elements. Enterprise-specific Information Elements are described in Sections 2.1 and 4.
ToP   noToC   RFC5102 - Page 82
   However, before creating enterprise-specific Information Elements,
   the general applicability of such Information Elements should be
   considered.  IPFIX does not support enterprise-specific abstract data
   types.

7. IANA Considerations

7.1. IPFIX Information Elements

This document specifies an initial set of IPFIX Information Elements. The list of these Information Elements with their identifiers is given in Section 4. The Internet Assigned Numbers Authority (IANA) has created a new registry for IPFIX Information Element identifiers and filled it with the initial list in Section 4. New assignments for IPFIX Information Elements will be administered by IANA through Expert Review [RFC2434], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested Information Element for completeness and accuracy of the description and for correct naming according to the naming conventions in Section 2.3. Requests for Information Elements that duplicate the functionality of existing Information Elements SHOULD be declined. The smallest available identifier SHOULD be assigned to a new Information Element. The specification of new IPFIX Information Elements MUST use the template specified in Section 2.1 and MUST be published using a well-established and persistent publication medium. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups.

7.2. MPLS Label Type Identifier

Information Element #46, named mplsTopLabelType, carries MPLS label types. Values for 5 different types have initially been defined. For ensuring extensibility of this information, IANA has created a new registry for MPLS label types and filled it with the initial list from the description Information Element #46, mplsTopLabelType. New assignments for MPLS label types will be administered by IANA through Expert Review [RFC2434], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts must double check the label type definitions with already defined label types for completeness, accuracy, and redundancy. The specification of new MPLS label types MUST be published using a well-established and persistent publication medium.
ToP   noToC   RFC5102 - Page 83

7.3. XML Namespace and Schema

Appendix B defines an XML schema for IPFIX Information Element definitions. All Information Elements specified in this document are defined by the XML specification in Appendix A that is a valid XML record according to the schema in Appendix B. This schema may also be used for specifying further Information Elements in future extensions of the IPFIX information model in a machine-readable way. Appendix B uses URNs to describe an XML namespace and an XML schema for IPFIX Information Elements conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been made. 1. Registration for the IPFIX information model namespace * URI: urn:ietf:params:xml:ns:ipfix-info-15 * Registrant Contact: IETF IPFIX Working Group <ipfix@ietf.org>, as designated by the IESG <iesg@ietf.org>. * XML: None. Namespace URIs do not represent an XML. 2. Registration for the IPFIX information model schema * URI: urn:ietf:params:xml:schema:ipfix-info-15 * Registrant Contact: IETF IPFIX Working Group <ipfix@ietf.org>, as designated by the IESG <iesg@ietf.org>. * XML: See Appendix B of this document.

8. Security Considerations

The IPFIX information model itself does not directly introduce security issues. Rather, it defines a set of attributes that may for privacy or business issues be considered sensitive information. For example, exporting values of header fields may make attacks possible for the receiver of this information, which would otherwise only be possible for direct observers of the reported Flows along the data path. The underlying protocol used to exchange the information described here must therefore apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. Such protocols are defined in separate documents, specifically the IPFIX protocol document [RFC5101]. This document does not specify any Information Element carrying keying material. If future extensions will do so, then appropriate precautions need to be taken for properly protecting such sensitive information.
ToP   noToC   RFC5102 - Page 84

9. Acknowledgements

The editors thank Paul Callato for creating the initial version of this document, and Thomas Dietz for developing the XSLT scripts that generate large portions of the text part of this document from the XML appendices.

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5101] Claise, B., "Specification of the IPFIX Protocol for the Exchange", RFC 5101, January 2008.

10.2. Informative References

[IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985. [IEEE.802-11.1999] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 1999, <http://standards.ieee.org/getieee802/download/802.11- 1999.pdF>. [IEEE.802-1Q.2003] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", IEEE Standard 802.1Q, March 2003. [IEEE.802-3.2002] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Standard 802.3, September 2002.
ToP   noToC   RFC5102 - Page 85
   [ISO.10646-1.1993]
              International Organization for Standardization,
              "Information Technology - Universal Multiple-octet coded
              Character Set (UCS) - Part 1: Architecture and Basic
              Multilingual Plane", ISO Standard 10646-1, May 1993.

   [ISO.646.1991]
              International Organization for Standardization,
              "Information technology - ISO 7-bit coded character set
              for information interchange", ISO Standard 646, 1991.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC1108]  Kent, S., "U.S. Department of Defense Security Options for
              the Internet Protocol", RFC 1108, November 1991.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1323]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, May 1992.

   [RFC1385]  Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385,
              November 1992.

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines for creation,
              selection, and registration of an Autonomous System (AS)",
              BCP 6, RFC 1930, March 1996.

   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113, February
              1997.
ToP   noToC   RFC5102 - Page 86
   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Structure of Management Information Version 2 (SMIv2)",
              STD 58, RFC 2578, April 1999.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, August 1999.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
              "Securing L2TP using IPsec", RFC 3193, November 2001.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, April 2002.

   [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
              P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
              Protocol Label Switching (MPLS) Support of Differentiated
              Services", RFC 3270, May 2002.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444, January
              2003.
ToP   noToC   RFC5102 - Page 87
   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC3954]  Claise, B., Ed., "Cisco Systems NetFlow Services Export
              Version 9", RFC 3954, October 2004.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
              2006.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4382]  Nadeau, T., Ed., and H. van der Linde, Ed., "MPLS/BGP
              Layer 3 Virtual Private Network (VPN) Management
              Information Base", RFC 4382, February 2006.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", RFC 4443, March
              2006.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, October 2007.


(next page on part 5)

Next Section