RFC 5102
Information Model for IP Flow Information Export
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
5.9.2. flowEndSeconds
Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeSeconds ElementId: 151 Status: current Units: seconds5.9.3. flowStartMilliseconds
Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeMilliseconds ElementId: 152 Status: current Units: milliseconds5.9.4. flowEndMilliseconds
Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeMilliseconds ElementId: 153 Status: current Units: milliseconds5.9.5. flowStartMicroseconds
Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeMicroseconds ElementId: 154 Status: current Units: microseconds5.9.6. flowEndMicroseconds
Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeMicroseconds ElementId: 155 Status: current Units: microseconds
5.9.7. flowStartNanoseconds
Description: The absolute timestamp of the first packet of this Flow. Abstract Data Type: dateTimeNanoseconds ElementId: 156 Status: current Units: nanoseconds5.9.8. flowEndNanoseconds
Description: The absolute timestamp of the last packet of this Flow. Abstract Data Type: dateTimeNanoseconds ElementId: 157 Status: current Units: nanoseconds5.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.
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: milliseconds5.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: milliseconds5.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: milliseconds5.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
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: octets5.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
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: current5.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: octets5.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: octets5.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
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: packets5.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: packets5.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
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: packets5.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: octets5.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: packets5.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
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: packets5.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: packets5.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
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: packets5.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: octets5.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.
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.
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 | +-----+---------------------------+-----+---------------------------+
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: seconds5.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: seconds5.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.
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.
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: current6. 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.
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.
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.
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.
[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.
[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.
[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)
