2 * Copyright (c) 2022 PANTHEON.tech, s.r.o. and others. All rights reserved.
4 * This program and the accompanying materials are made available under the
5 * terms of the Eclipse Public License v1.0 which accompanies this distribution,
6 * and is available at http://www.eclipse.org/legal/epl-v10.html
9 * NETCONF Secure Transport layer interfaces. These cover establishment of a the persistent connection and managing its
10 * lifecycle. See <a href="https://www.rfc-editor.org/rfc/rfc6241#page-9">RFC6241 Figure 1</a> for the architectural
11 * placement in the NETCONF stack.
14 * In traditional NETCONF operation NETCONF server listens for TCP connections and NETCONF clients connect to it. In
15 * <a href="https://www.rfc-editor.org/rfc/rfc8071#section-2">Call Home</a>, the TCP layer operates the other way
16 * around, i.e. NETCONF clients listen for TCP connections and NETCONF servers connect to it. Once the TCP session is
17 * established, though, it is the client which initiates both transport-level and NETCONF-level handshakes.
20 * Both scenarios are handled by a single set of interfaces:
22 * <li>a {@link TransportStack} represents a transport instance -- a server or a client in either liste or connect
24 * <li>a {@link TransportChannel} represents a transport session -- there can be multiple concurrent
25 * {@code TransportChannel}s associated with a listening client or server, but only one associated with a
26 * connecting client or server.</li>
27 * <li>a {@link TransportChannelListener} is the primary callback mechanism towards client code. Its methods are
28 * invoked when a {@link TransportChannel} is established successfully or a failure to establish a channel is
32 package org.opendaylight.netconf.transport.api;