IGP Monitoring Protocol (IMP)

With the growing number of network programmability and central control there is an increased need to share topology, link and node information from each IGP area. Such requirements traditionally were fulfilled by establishing an IGP adjacency between such central entities and selected nodes in each area. Often that adjacency was established over a tunnel interface. In recent years selected link state and TE information have been carried by BGP4 extension called BGP-LS . However with the growing number of IGP extensions, application aware networking (APN), new per node network actions and ongoing link state protocols extensions load of BGP-LS on BGP protocol development, testing and deployments keeps increasing. Moreover BGP is a point-to-multipoint protocol which does not make it a good fit to propagate point-to-point information. In addition to the above requirements IGP Monitoring Protocol should provide ability to simplify operations of the network and assist when enhanced troubleshooting is required. The below proposal addresses that requirement as well. The primary inspiration for this work has been based on the success of BGP Monitoring Protocol (BMP) which in a number of aspects shares the same high level requirements - point to point routing information distribution, protocol observability and enhanced operations. It also needs to be highlighted that BMP (while it technically could) does not use native BGP sessions to propagate such information, but is running a separate transport. IMP authors have chosen to reuse selected BMP building blocks and BMP operational and deployment experience.

IGP - Interior Gateway Protocol
LSDB - Links State Database
TED - Traffic Engineering Database
OSPF - Open Shortest Path First
ISIS - Intermediate System to Intermediate System Protocol
SPAN - Switched Port Analyzer
YANG - Yet Another Next Generation
DBD - Database Description
CSNP - Complete Sequence Number PDU
PSNP - Partial Sequence Number PDU
TLV - Type Length Value
LSA - Link State Advertisement
LSP - Link State PDU
PDU - Protocol Data Unit
QUIC - Quick UDP Internet Connections

IGP Monitoring Protocol messages can be transported over either TCP session or UDP based QUIC transport . The use of QUIC protocol is recommended however for backwards compatibility with existing deployments of BGP-LS use of TCP session can also be leveraged. Irrespective of the choice of transport layer the IMP messages would remain identical. TCP session SHOULD be configured with TCP AO and QUIC SHOULD be used with its native security. IMP operates in point-to-point mode. What information is sent can be either configured statically or learned dynamically in a PUB-SUB fashion. IMP protocol operates between two nodes: Producer and Receiver. The ultimate destination can be many Producer-Receiver hops away. The following modes of operations are independently permitted for each data type:

MODE "A" - PUSH - Only IMP DATA messages containing given data type(s) are sent only from Producer to Receiver(s). What is being sent is subject to local configuration on the Producer. No filtering is permitted on the Producer.
MODE "B" - F_PUSH - IMP DATA messages are sent from Producer to Receiver. Receiver may request a subset of data types by sending FILTER message(s) to the Producer. Producer may honor that filter or drop it.
MODE "C" - PUB-SUB - Before any DATA messages are sent from Producer, Receiver MUST register interest in specific data type(s) by sending REQUEST messages.
MODE "D" F_PUB-SUB - MODE "C" with subset of data as communicated by Receiver in sending FILTER message(s).

The below common header will appear in all IMP messages.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg. Type | +---------------+

o Version (1 byte): Indicates the IMP version. This is set to '1' for all messages defined in this specification. Versions 0 and 255 are reserved and MUST NOT be used.
o Message Length (4 bytes): Length of the message in bytes (including common header, data, and encapsulated messages, if any).
o Message Type (1 byte): This identifies the type of the IMP message. An IMP implementation MUST ignore unrecognized message types upon receipt. This document defines the following type codes:

1 - DATA
2 - REQUEST
3 - FILTER

IMP can carry different types of protocol and local system data. All types of DATA Messages are propagated from Producer to Receiver(s). Except DATA Type 1 all other DATA Types are optional. All DATA Types are subject to both implementation exposure and operator's permission. The following figure illustrates DATA Message Header:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router Identifier - Producer's 4 octet Router ID to uniquly identify the sender data. For ISIS if 4 octet Router ID is not configured IPv4 address of lowest loopback interface SHOULD be used. DATA Type - The below list of DATA Types are defined by this specification. DATA Type 0x0000 and 0xFFFF are reserved for special use. IMP specification focuses on propagating information carried in link state protocols along with any extensions. The base specifications for protocols are: OSPFv2 , OSPFv3 and ISIS .

DATA Type 1 - BGP-LS NLRI of AFI 16388 SAFI 71
DATA Type 2 - BGP-LS NLRI of AFI 16388 SAFI 72

DATA Type 3 - OSPFv2 native LSDB Synchronization using DBDs
DATA Type 4 - OSPFv3 native LSDB Synchronization using DBDs
DATA Type 5 - ISIS native LSDB Synchronization using CSNPs
DATA Type 6 - ISIS native LSDB Synchronization using PSNPs

DATA Type 7 - OSPFv2 LSDB Content - YANG model
DATA Type 8 - OSPFv3 LSDB Content- YANG model
DATA Type 9 - ISIS LSDB Content - YANG model

DATA Type 10 - OSPFv2 and OSPFv3 packets inbound mirroring
DATA Type 11 - OSPFv2 and OSPFv3 packets onbound mirroring
DATA Type 12 - ISIS PDUs inbound mirroring
DATA Type 13 - ISIS PDUs outbound mirroring

DATA Type 14 - OSPFv2 configuration - XML format
DATA Type 15 - OSPFv2 configuration - JSON format
DATA Type 16 - OSPFv3 configuration - XML format
DATA Type 17 - OSPFv3 configuration - JSON format
DATA Type 18 - ISIS configuration - XML format
DATA Type 19 - ISIS configuration - JSON format

An implementation MAY provide means to apply additional filtering to send only subset of DATA Types or fields within specific DATA Type. An implementation MAY provide facilities to define thresholds where a given type of information may be sent immediately or could be sent with predefined delay only when the absolute value contained exceeds threshold. For DATA Types containing BGP-LS data the encoding is identical to what is defined in the main BGP-LS specification and all extensions. The nature of data is incremental and only changes are propagated. Native LSBD synchronization the data block follows frequency of identical data sent to any neighbour. Structured DATA Types using YANG, XML or JSON encoding first data block should contain the entire dataset followed by incremental updates only when changes occur. Raw DATA Types are asynchronous by design and reflect what protocol communication takes place on a given interface(es).

REQUEST Message is an optional IMP message allowing Receiver to list what DATA Types it is interested in receving. The following figure illustrates REQUEST Message type:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1-N DATA Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Receiver Identifier - Receiver's domain wide unique 4 octet identifier. Enumerated DATA Types included in REQUEST Message payload indicate to the Producer which DATA Types Receiver is subscribing to. REQUEST Message containing DATA Type 0x0000 indicates unsubscription from any DATA Types. Each non-empty consecutive REQUEST Message received from a given Receiver is an implicit withdrawal of any previously received subscription. It is also an explicit overwrite of any locally configured permit policy. The size of valid REQUEST Message including Common Header is 10+(N*2) octets where N >= 1.

FILTER Message is an optional IMP message allowing Receiver to send additional set of filters to what subset of specific protocol messages within DATA Types it is interested in receiving. The following figure illustrates FILTER Message type:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1-N FILTER TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Receiver Identifier - Receiver's domain wide unique 4 octet identifier. DATA Types included in FILTER Message indicate to which DATA Types enclosed filter TLVs apply. Minimal FILTER Message size including Common Header is 12 octets (no FILTER TLVs is included). Meaning of such message is removal of all previously advertised filters for a given DATA Type. Each non-empty consecutive FILTER Message received from a given Receiver is an implicit withdrawal of any previously received subscription. TLVs sent are replacing any previously sent FILTERS for a given DATA Type. Filter TLVs are scoped and their structure depends on the DATA Type they are to filter. Presence of multiple TLVs in a FILTER Message is a logical AND. A single FILTER message may contain Filter TLVs of multiple types.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLV Type: Fixed two octet number indicating name of the defined TLV
Length: Fixed two octet length of the TLV including its header in octets
Value: Variable size in multiplication of octets containing the filter value

The following Filter TLVs are defined in this document. Definition of more Filter TLVs may be added in this or any future specificiations.

Type 1: BGP-LS NLRI Type
Length: 5 octets
Value: 1 octet - IANA Registry: BGP-LS NLRI-Types
Applicability: DATA Type 1, DATA Type 2

Type 2: BGP-LS Descriptors
Length: 6 octets
Value: 2 octet - IANA Registry: BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs
Applicability: DATA Type 1, DATA Type 2

Type 3: OSPFv2 DBD LS Type
Length: 5 octets
Value: 1 octet - IANA Registry: OSPFv2 Link State (LS) Type
Applicability: DATA Types: 3, 7, 10, 11

Type 4: OSPFv3 DBD LSA Function Codes
Length: 6 octets
Value: 2 octet - IANA Registry: OSPFv3 LSA Function Codes
Applicability: DATA Types: 4, 8, 10, 11

Type 5: ISIS Top-Level TLV Codepoints
Length: 6 octets
Value: 2 octet - IANA Registry: IS-IS Top-Level TLV Codepoints
Applicability: DATA Types: 5, 6, 9, 12, 13

Network elements may support multiple instances of IGP protocols. The IMP Messages as defined in this specification are applicable to a single IGP instance. When multiple IGP instances are enabled each should maintain a separate IMP session. In such cases each instance also should identify itself with a different 4 octet Router-ID.

While the specification defines protocol to operate between two nodes a given deployment may operate across more then two nodes. An IMP node may act as Producer's proxy. In such a scenario the same node can act as Receiver on one side and as Producer for other Receiver(s) on the other one. Different TCP ports MAY be used on a per session basis. The focus of IMP is to feed operational data to network controllers and assist in network monitoring, analysis and debugging. But is it also directly possible to share information about the state of nodes and/or links from a given area to other areas in a form of unicast instead of using native IGP flooding. This is especially interesting when information shared is required by a subset of routers in other areas. For example, indication of node down events can be propagated using IMP to any other interested nodes. For scalability use of one or more Producer's proxies is recommended. When an IMP Producer receives an unrecognized message or unrecognized type such message SHOULD be ignored and error notification sent to system log. Currently authors purposely did not extend the protocol with a separate ERROR Message to communicate back to the Receiver the unrecognized part of the REQUEST or FILTER Message. When an IMP Receiver detects an unrecognized part of DATA Message it should log it locally and if possible continue parsing the remaining data.

This document does not require any new capability to be defined.

This document defines a new IGP Monitoring Protocol (IMP) and it is expected that IANA creates a new group as well as a number of following registries to maintain its parameters.

This document defines 1 octet IMP message types to be tracked by IMP Message Type Registry. Currently three values are defined:

1 - DATA
2 - REQUEST
3 - FILTER

Values 0 and 255 are to be marked as Reserved. Type values 1 through 127 MUST be assigned using the "Standards Action" policy, and values 128 through 250 using the "Specification Required" policy defined in . Values 251 through 254 are Experimental.

This document defines two octet DATA Types to be tracked by IMP DATA Types Registry. Currently nighteen values are defined:

DATA Type 1 - BGP-LS NLRI of AFI 16388 SAFI 71
DATA Type 2 - BGP-LS NLRI of AFI 16388 SAFI 72
DATA Type 3 - OSPFv2 native LSDB Synchronization using DBDs
DATA Type 4 - OSPFv3 native LSDB Synchronization using DBDs
DATA Type 5 - ISIS native LSDB Synchronization using CSNPs
DATA Type 6 - ISIS native LSDB Synchronization using PSNPs
DATA Type 7 - OSPFv2 LSDB Content - YANG model
DATA Type 8 - OSPFv3 LSDB Content- YANG model
DATA Type 9 - ISIS LSDB Content - YANG model
DATA Type 10 - OSPFv2 and OSPFv3 packets inbound mirroring
DATA Type 11 - OSPFv2 and OSPFv3 packets onbound mirroring
DATA Type 12 - ISIS PDUs inbound mirroring
DATA Type 13 - ISIS PDUs outbound mirroring
DATA Type 14 - OSPFv2 configuration - XML format
DATA Type 15 - OSPFv2 configuration - JSON format
DATA Type 16 - OSPFv3 configuration - XML format
DATA Type 17 - OSPFv3 configuration - JSON format
DATA Type 18 - ISIS configuration - XML format
DATA Type 19 - ISIS configuration - JSON format

Values 0 and 65535 are to be marked as Reserved. Type values 1 through 32767 MUST be assigned using the "Standards Action" policy, and values 32768 through 65530 using the "Specification Required" policy defined in . Values 65531 through 65534 are Experimental.

IANA is to allocate FILTER TLV Types Registry. This document defines two octet FILTER TLV Types to be tracked by IMP FILTER TLV Types Registry. Currently five values are defined:

Type 1: BGP-LS NLRI Type
Type 2: BGP-LS Descriptors
Type 3: OSPFv2 DBD LS Type
Type 4: OSPFv3 DBD LSA Function Codes
Type 5: ISIS Top-Level TLV Codepoints

This document defines a new method to obtain link state protocol data from network elements. The protocol defines a number of deployment scenarios, however critical network infrastructure is not expected to support all of them. Their role should be limited to export information to a minimal number of Receivers. It is the Receiver which can further filter the available information (acting as Producer's proxies) and share further optionally in PUB-SUB mode to interested parties. Due to the very sensitive nature of the link state data IMP sessions MUST either be authenticated (TCP-A0) or native protocol security enabled (QUIC). The allowed peers to exchange IMP messages SHOULD be explicitly configured. In cases where TCP is used the listening port is subject to a local configuration by the operator to even further make it not a well known attack target. In deployments where the security considerations outlined above are still a concern, users of this protocol should use IPsec in tunnel mode with pre-shared keys.

....