Logical Interface Support for multi-mode IP Hosts : 3. 상세기능

논리 인터페이스의 상세 기능

이 절에서는 논리 인터페이스의 상세한 기능에 대해 다루며, 몇가지 구현상의 고려사항 또한 제공한다.

대부분의 운영체제에서, 네트워크 인터페이스는 물리 장비와 연결되어, IP 패킷으로부터 송수신한 패킷을 호스트상의 어플리케이션에 제공한다. 설정을 통하여, 네트워크 인터페이스는 논리 인터페이스로 구현되며, 논리 인터페이스는 물리 매체로부터 패킷을 수/발신 할 수 있는 기능을 가지고 있지 않지만, 그 대신 다른 물리 인터페이스에 의지하여 해당 작업을 수행한다. 이 설정의 예로서 IP 터널링 인터페이스를 들 수 있다.

논리 인터페이스의 일반적인 구조는 [그림 2]에서와 같이 보여질 수 있다. 논리 인터페이스는 heterogeneous한 접속을 허용하며, IP 스택에서 변화를 인지하지 못하게 한다. 동시/순차적인 네트워크 접속 과정은 기술간의 시나리오와 flow mobility 시나리오를 가능하게 한다.

IP 스택과 어플리케이션의 입장에서, 논리 인터페이스는 단지 또다른 인터페이스에 지나지 않는다. 사실, 논리 인터페이스는 활성화 되었을 경우에만 IP와 상위 계층에 보이게 된다. 호스트는 논리 인터페이스와 물리 인터페이스의 차이를 느끼지 못한다. 물리 인터페이스와 함께하여, 논리 인터페이스는 IP 주소 설정이 바인딩 된, 소프트웨어 객체로서 표현된다. 하지만, 논리 인터페이스는 기술간 핸드오버나 flow mobility 기능들을 활성화 하는데 필수적인 다음과 같은 성질을 가지고 있다. 

1. 논리 인터페이스는 추상화되는 호스트 상의 물리 인터페이스(sub-if)의 집합과 관계가 있다. 이 sub-if들은 언제든 논리 인터페이스에 추가되거나 제거될 수 있다. 논리 인터페이스에 추가된 sub-if는 IP나 상위 계층에서 보이지 않는다.

2. 논리 인터페이스는 각각의 sub-if들의 인터페이스 ID와 독립적인 가상 인터페이스 ID를 사용할 수 있기도 하고, sub-if의 링크계층 ID를 사용할 수도 있다.

3. 논리 인터페이스는 연결된 IP 네트워크에 대한 경로 인지기능을 가지고 있다. 예를 들어, 논리 인터페이스가 두개의 IP 네트워크인 CAFE::/64와 BABA::/64에 연결되었다 한다면, 각각의 prefix들은 각기 다른 sub-if(WLAN, LTE)에 사용되어 연결될 것이다. 논리 인터페이스는 IP 네트워크와 sub-if의 매핑을 통해 경로 인지기능을 가지는 것이다.

4. 논리 인터페이스는 각기 다른 MTU 값을 가지는 다중 엑세스 기술으로 연결될 수 있다. 논리 인터페이스에서 사용되는 MTU 값은 각기 다른 기술들 중에서 가장 낮은 MTU 값보다 낮아야 한다.

5. 논리 인터페이스의 송/수신 기능은 sub-if들에 상응하는 부분으로 매핑된다. 이 매핑은 유동적이며 여기에서의 변화는 IP 스택의 상위 계층에서는 보이지 않는다.

6. 논리 인터페이스는 점-대-점 링크 모델을 따른다.

7. 논리 인터페이스는 각각의 sub-if에 대한 IP flow 정보를 유지한다. 개념적 데이터 구조가 이 용도를 위해 사용된다. 호스트는 각각의 sub-if들의 flow들을 살펴봄으로서 이 정보를 얻을 수 있다.

논리 인터페이스의 설정

호스트는 논리 인터페이스로 정적으로 설정할 수 있거나, 호스트상의 연결 관리기와같은 어플리케이션을 사용하여 논리 인터페이스를 생성할 수 있다. 또한, 논리 인터페이스를 이루는 sub-if의 집합은 고정되거나 혹은 유동적일(sub-if가 필요할때마다 추가/삭제 가능한) 수 있다.

논리 인터페이스의 MTU 고려

링크 Maximum Transmission Unit(MTU)값은 논리 인터페이스 상에서 설정되고, 여기에는 논리 인터페이스를 구성하는 물리 인터페이스들 중 가장 낮은 MTU 값이 설정되어야 한다. MTU 값은 호스트에서 논리 인터페이스 생성시에 설정되어야 한다.

그리고 이 값은, 논리 인터페이스에서 인터페이스가 추가되거나 삭제되는 경우와 같은, 논리 인터페이스의 구조 변경시마다 갱신되어야 한다, 두 접근 기술 간의 핸드오버가 일어날 때마다, 논리 인터페이스에 대한 IP 주소가 설정된 호스트상의 어플리케이션은 변화를 인지하지 못할 것이고, 따라서 송신 패킷에 대해 논리 인터페이스의(지원하는 접근 네트워크의 MTU 값보다 절대 높지 않는) MTU값을 그대로 사용할 것이다. 하지만, 접근 네트워크는 그 접속 기술이 지원하는 MTU 값을 준수하며 패킷을 전송할 것이고, 논리 인터페이스는 그 네트워크에 접속한 물리 인터페이스로부터의 패킷을 받을 수 있을 것이다. MTU 설정으로의 이 방법은 기술간 핸드오버시에 IP 패킷 단편화가 일어나지 않을것이라는 것을 보장한다.

논리 인터페이스를 위한 링크 모델

Proxy Mobile IPv6 문서[RFC5213]에 따르면 물리 인터페이스하의 매체는 점-대-점 연결로 한정된다. [RFC5213] 공유된 매체를 제공하는 접근 기술(IEEE 802.11과 같은)은 점-대-점 연결을 제공하는 이를 지원한다. [RFC4861] 공유 매체가 어떻게 점-대-점 연결성을 제공하는가에 대한 자세한 사항은 링크 계층에 한정적이고, 따라서 운영에 대한 사항은 이 문서의 범위를 넘어선다. IEEE 802.11 매체는 적절한 IEEE 802.1Q VLAN 헤더를 사용함으로서 점-대-점 연결을 제공할 수 있으며, 이때 각각의 VLAN은 MAG과 각 MN간에 설정되거나 MAG 상에서 layer-2 유니캐스트 패킷으로서 멀티캐스트를 전송하는 방법으로 설정될 수 있다. 따라서 공유 링크 상에서 점-대-점 연결특성을 보존할 수 있다.

논리 인터페이스를 위한 링크계층 ID 선택

논리 인터페이스는 sub-if들중의 하나로부터, 혹은 그들과 개별적으로, 링크계층 ID를 사용하도록 설정될 수 있다. 다음과 같은 고려사항이 존재한다.

* 가상 링크계층 ID를 사용할 수 있고, 이를 어떠한 네트워크에서의 2계층 통신을 위해 사용할 수 있는 엑세스 구조에서, 가상 ID(VLL-ID)가 사용될 수 있다. ID가 어떻게 선택되는가는 이 문서의 범위를 넘어선다. ID는 모든 링크계층 통신에 사용될 수 있다. ID는 stateless autoconfiguration[RFC4862]에 기반한 글로벌/링크로컬 주소를 생성할 때 인터페이스 ID로서 사용될 수 있다. 

* 링크계층 ID가 특정 엑세스 기술에 연관되어 있는 엑세스 구조에서, 가상 ID를 사용하는것이 불가능할 것이고 논리 인터페이스는 각기 다른 네트워크에 연결될 것이다. 이러한 네트워크상에서, 논리 인터페이스는 패킷이 전송되는 각각의 sub-if의 ID를 사용하여야 한다. 하지만, 만약 논리 인터페이스상의 하나 이상의 엑세스 기술 도메인에서 이러한 요구가 있을 경우에는, 논리 인터페이스는 이와 같은 설정을 지원하지 못한다.

논리 인터페이스상에서의 ND에 대한 고려사항

아래는 논리 인터페이스를 사용하는 환경에서의 Neighbor Discovery[RFC4861]에 관한 내용이다.

* 호스트가 링크로컬 범위의 멀티캐스트 목적지 주소(all-nodes, all-routers, solicited-node multicast group

addresses, using either an unspecified (::) source address, or a link-local address configured on the logical interface)로 전송하게 하는, RS, NS, NA 등과 같은 ND 메시지는 복제되고, 논리 인터페이스의 각각의 sub-if로 포워드 된다. 하지만 만약 목적지 주소가 유니캐스트 주소이고 목적지가 특정한 sub-if로 향한다면, 패킷은 특정 sub-if에만 포워드 되고 다른 sub-if에까지 복제되지는 않는다

* 호스트가 논리 인터페이스의 sub-if들에서부터 받는 RA와 같은 ND메시지는 논리 인터페이스와 연관되어, 몇몇 구현에서는 패킷이 논리 인터페이스의 입력 인터페이스에 나타날 것이다.

* Stateless address autoconfiguration을 사용하여 논리 인터페이스 상에서 IPv6 주소를 생성한다면, 호스트는 각각의 sub-if들로부터 받은 RA 메시지로부터의 IPv6 prefix들 중 아무거나 사용하여 주소를 생성할 수 있다.

* 유니캐스트, 링크특정 멀티캐스트 그룹주소로부터 받은 ND 메시지에 대한 응답은 패킷이 받은 동일한 sub-if 경로를 통해 보내진다.

* DHCPv4를 사용하여 논리 인터페이스의 주소설정을 받아온다면, DHCP 메시지 내의 chaddr 필드의 값은 논리 인터페이스에 의해 선택된 링크 계층 ID 구조에 기반한 것이다.

도메인 고려사항

다중 인터페이스를 가진 호스트에서의 다중 도메인의 제공에 대한 고려는 RFC 6418에서 다루어졌다. 이 고려는 DNS 설정에 중점이 맞춰져 있다. 하지만, 논리 인터페이스의 측면에서는, 이러한 고려들이 적용되지 않는다. 왜냐하면 논리 인터페이스는 하나의 도메인에 한해 지원되기 때문이다. 논리 인터페이스의 중요한 사항은 기술간 핸드오버이고, 핸드오버는 하나의 도메인 내에서만 이루어진다.

LIF 데이터 구조

논리 인터페이스는 해당 sub-if들의 목록을 가진다. 이 개념적 데이터 구조는 Logical Interface Forwarding(LIF) 테이블이라 부른다. 논리 인터페이스는 또한 각 sub-if에 해당하는 flow의 리스트 또한 가지고 있고 이는 PIF 테이블이라 부른다. 이 데이터 구조들은 논리 인터페이스와 연관되며, 이는 [그림 3]에 나타나있다.

[그림 3] 논리 인터페이스 내 데이터 구조

LIF에는 LIF와 LIF와 연관된 각각의 PIF간의 매핑이 기재되어 있다. 각각의 PIF 항목에 대해 테이블은 연관되는 라우팅 정책, RA메시지로 얻은 HNP, 설정된 링크 계층 주소, PIF의 정보(예를들어 Active/Not Active)를 가지고 있어야 한다. 

FLOW 테이블은 논리 인터페이스가 각각의 IP flow를 올바른 인터페이스로 라우트 하도록 해준다. 논리 인터페이스는 sub-if로 오는 flow를 확인할 수 있으며, 이를 각각의 sub-if에 대해 연관지을 수 있다. 이러한 방법은 IP 라우터에 의해 수행되는 반영적(reflective) QoS와 유사하다. 로컬에서 생성된 트래픽(예를 들어 유니캐스트 flow)에 대해서는, 논리 인터페이스는 flow 라우팅 정책에 근거하여 인터페이스를 선택해야 한다. 기존의 flow의 트래픽이 갑자기 기존의 것과 다른 sub-if에서 받아진다면, 논리 인터페이스는 이 상황을 네트워크로부터의 명백한 flow mobility 트리거로 인지하고, FLOW 테이블내의 PIF_ID 속성을 업데이트해야 한다. 이와 비슷하게, sub-if로부터의 로컬에서 생성된 이벤트 또는 로컬 정책에 대한 설정 변경은 테이블에 갱신을 초래할 수 있으며 따라서 flow mobility를 유발할 수 있다.