KR20180104377A - 패킷 광 전송 네트워크를 통한 클라우드 간 가상 네트워킹 제공 방법 - Google Patents

Abstract

클라우드간 멀티테넌트 가상 네트워크 서비스 제공 방법이 개시된다. 본 발명의 실시예는 최근 점차 도입이 확대되고 있는 패킷 광전송망 환경을 이용하여 클라우드간 멀티테넌트 가상 네트워크를 제공하기 위한 방법을 제공한다. 클라우드 간 가상 테넌트 네트워크의 패킷에는 각각의 클라우드 내에서 가상네트워크를 구분하기 위한 가상 네트워크 식별자(VLAN ID 또는 VxLAN ID 등)와는 독립된 가상 네트워크 식별자가 패킷 광전송망에서 할당되며, 전용의 외부 게이트웨이 인터페이스를 통하여 패킷 광전송망으로 라우팅될 수 있다.

Description

패킷 광 전송 네트워크를 통한 클라우드 간 가상 네트워킹 제공 방법{Method for inter-cloud virtual networking over packet optical transport network}

본 발명은 가상 네트워크를 제공하는 방법에 관한 것으로, 더욱 상세하게는 지역적으로 분산된 클라우드 데이터 센터 간에 가상 멀티테넌트 네트워크를 제공하고 제어하는 방법에 관한 것이다.

클라우드 컴퓨팅이 빠르게 확산됨에 따라 전세계적으로 ICT(Information & Communications Technology) 자원을 클라우드로 전환하거나 클라우드 사업자의 서비스를 이용하는 추세가 증가하고 있다. 특히, 대규모 클라우드 사업자의 경우, 단일 클라우드 데이터센터가 아닌 지역적으로 분산된 다수의 클라우드 데이터센터를 구축하여 서비스의 부하분산 및 지연에 민감한 서비스를 사용자와 가까운 데이터센터에 배치함으로써 서비스 품질을 보장하고 있다. 또한, 오늘날 IoT(Internet of Things)나 NFV(Network Functions Virtualization) 기술의 개발 및 도입 계획에 따라, 앞으로 지역적으로 분산된 크고 작은 다수의 클라우드가 상호 연동되는 환경은 점차 보편화될 것으로 전망된다.

가상 인프라 환경을 서비스로서 제공(IaaS, Infrastructure as a Service)하는 클라우드 환경에서 단일 클라우드 내에서 사용자의 가상 네트워크(Intra-Cloud Virtual Network)를 제공함에 있어 제한된 또는 승인된 사용자 그룹에게만 격리된 네트워킹 환경을 제공하는 멀티 테넌시(multi-tenancy)의 보장은 VLAN(Virtual LAN)이나 VxLAN(Virtual Extended LAN), NVGRE(Network Virtualization using Generic Routing Encapsulation) 등의 오버레이 기술로서 제공이 가능하다.

또한, 이를 확장하여 지역적으로 분산된 복수의 클라우드 환경에서 사용자의 멀티테넌트 가상 네트워크를 클라우드 영역을 벗어나 원격의 클라우드까지 확장할 수 있는 멀티테넌트 인터 클라우드 네트워킹(Multitenant Inter-Cloud Networking) 기술의 필요성이 대두되고 있다. 현재로서는 멀티테넌트 인터 클라우드 기술은 클라우드 사이의 네트워크를 사업자가 독점하여 제어하는 고비용의 물리적인 전용망을 구성하거나, 또는 인터넷 망을 이용하되 IPSec(IP Security) 등의 기술을 접목한 VPN(Virtual Private Network) 망을 구성하는 방안, 그리고 클라우드 사이의 네트워크를 SDN(Software Defined Networking) 기술을 적용하는 방안을 고려할 수 있다.

그러나, 종래 기술은 다음과 같은 특징이나 제약을 갖고 있다.

첫째, 물리적인 전용망의 경우, 광대역 고속 전송은 가능하지만, 클라우드 사업자 또는 사설 클라우드를 구축하고자 하는 기업이나 기관에게 막대한 비용의 투자를 요구하며, 네트워크 가상화 기술을 접목하지 않는 경우 멀티테넌트 네트워킹을 효과적으로 제공하지 못하는 제약을 갖는다.

둘째, 인터넷 망을 통한 VPN의 경우, 소프트웨어 기반의 VPN 기능을을 구현함에 있어 패킷 처리 속도가 느려지는 문제점이 있으며, 단순히 IPSec 등과 같은 오버레이 기술을 적용하는 경우 가상 네트워크별로 서비스 품질을 보장하지 못하는 제약을 갖고 있으며, MPLS(Multi-protocol Label Switching) VPN을 적용하는 경우에는 MPLS의 특성상 서비스 품질의 제어는 가능하나 클라우드 사이의 네트워크가 모두 MPLS 네트워크로 구축되어야 하는 제약을 갖는다.

끝으로, SDN 기술을 적용하는 경우, 클라우드 사이의 네트워크가 모두 SDN 방식으로 제어가 가능한 네트워크 장비로 구축되어야 하는 조건을 충족해야 한다.

상기와 같은 문제점을 해결하기 위한 본 발명의 목적은, 서비스 품질이 보장되는 클라우드 간 멀티테넌트 가상 네트워크를 서비스하는 방법을 제공하는 것이다. 특히, 현실성이 부족한 클라우드간 네트워크 환경은 배제하고, 최근 통신사업자에 의해 백본망 뿐만 아니라 엑세스 망 영역까지 점차 도입이 확대되고 있는 패킷광전송 네트워크(POTN, Packet Optical Transport Networks) 환경에 기반한 클라우드간 멀티테넌트 가상 네트워크를 제공하기 위한 방법을 제공한다.

상기 목적을 달성하기 위한 본 발명은, 패킷 광전송망을 이용한 멀티테넌트 네트워크 서비스 제공 방법으로서, 제1 클라우드의 가상 라우터가 상기 제1 클라우드의 가상머신으로부터 패킷을 수신하는 단계; 상기 패킷이 클라우드 간 가상 테넌트 네트워크의 패킷인 경우, 상기 제1 클라우드의 가상 라우터가 상기 패킷을 클라우드 간 가상 테넌트 네트워크 연결을 위한 전용 외부 게이트웨이 인터페이스로 라우팅하는 단계; 상기 패킷이 패킷 광전송망을 거쳐 제2 클라우드의 외부 게이트웨이 인터페이스를 통하여 상기 제2 클라우드의 가상 라우터로 전달되는 단계; 및 상기 제2 클라우드의 가상 라우터가 상기 패킷을 상기 제2 클라우드의 가상머신으로 전달하는 단계를 포함하고, 상기 제1 클라우드와 상기 제2 클라우드 내의 가상 네트워크를 구분하기 위한 가상 네트워크 식별자와는 독립적인 가상 네트워크 식별자가, 상기 패킷 광전송망내에서 상기 패킷에 부여되는 것을 특징으로 하는, 패킷 광전송망을 이용한 멀티테넌트 네트워크 서비스 제공 방법을 제공한다.

본 발명의 구성에 따르면, 지역적으로 분산된 클라우드간 서비스 품질이 보장되는 멀티테넌트 가상 네트워크를 제공할 수 있으며, 이는 단일 클라우드 내부에 국한되었던 사용자의 가상 네트워크(Intra-Cloud Virtual Tenant Network)를 원격의 클라우드까지 확장할 수 있다. 특히, 최근 통신사업자에 의해 백본망 뿐만 아니라 엑세스 망 영역까지 도입이 확대되고 있는 패킷광전송 네트워크(POTN)에 기반한 다양한 가상 네트워크 기반의 서비스의 제공이 가능할 것이다.

또한, NFV와 IoT 기술의 발달 및 도입에 따라 지역적으로 분산된 크고 작은 다수의 클라우드가 서로 연동되어 서비스를 제공해야 하는 필요성이 급증하고 있으며, 이러한 환경에서 서비스 품질이 보장되는 클라우드간 가상 테넌트 네트워크의 확장 기술은 서비스 제공자의 인프라 구축 및 서비스 제공 정책의 자유도 및 효율성을 극대화하고, 사용자에게는 보다 고품질의 서비스를 안정적으로 제공할 수 있는 효과가 있다.

도 1은 분산된 클라우드 환경에서의 클라우드 간 멀티테넌트 네트워크의 제공 개념을 설명하기 위한 개념도이다.
도 2는 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크의 제공 개념을 설명하기 위한 개념도이다.
도 3은 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크를 제공하기 위한 네트워크 노드의 구성을 설명하기 위한 블록도이다.
도 4는 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크 서비스를 제공하기 위한 오픈스택 환경 구성 절차를 설명하기 위한 흐름도이다.
도 5는 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크를 생성하는 절차를 설명하기 위한 순서도이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.

제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.

도 1은 분산된 클라우드 환경에서의 클라우드 간 멀티테넌트 네트워크의 제공 개념을 설명하기 위한 개념도이다.

도 1을 참조하면, 복수의 클라우드 데이터센터(DC1, DC2, DC3)가 여러 지역에 독립적으로 분산되어 구축되고 각 데이터센터는 각각의 단위 클라우드 데이터센터의 관리시스템(Local Cloud Controller; 111, 112 및 113)을 통해 서비스의 제공 및 제어 관리가 이루어진다.

이때, 각 데이터센터(DC1, DC2, DC3)는 외부망(인터넷망 또는 전용망 등; 150)과의 네트워킹 서비스를 제공하기 위한 외부 게이트웨이(External Gateway) 장비(121, 131, 141)를 통해 데이터센터 외부에 위치한 사용자로부터의 데이터센터 접속이나 웹 서비스 등을 제공하는 서버로의 접속 또는 데이터센터 간의 연결 서비스를 제공할 수 있다. 만일, 복수의 데이터센터를 통합적으로 관리하여 서비스를 제공하고자 하는 경우에는 각 단위 클라우드 데이터센터의 관리시스템(121, 131, 141)의 상위 계층에 글로벌 클라우드 데이터센터 관리시스템(Global Cloud Controller; 160)을 구축하여 운용할 수 있다.

단위 클라우드 데이터센터(DC1, DC2, DC3)는 클라우드 서비스의 제공을 위해 복수의 물리 서버와 L2/L3 네트워킹 장비, L4~L7 네트워킹 장비 및 스토리지 장비 등으로 구성될 수 있다. 각 물리 서버는 하이퍼바이저(hypervisor) 또는 컨테이너 엔진(container engine) 등의 가상화 소프트웨어를 통해 컴퓨팅 자원을 가상화하여 사용자에게 가상머신(Virtual Machine)이나 가상 컨테이너(Virtual Container) 등의 가상 컴퓨팅 인스턴스를 제공하며, 가상 컴퓨팅 인스턴스의 네트워킹 서비스를 제공하기 위해 Linux Bridge 또는 Open vSwitch 등과 같은 소프트웨어 기반의 가상 스위치(Virtual Switch)나 SR-IOV(Single Root I/O virtualization) 등과 같은 하드웨어 기반의 스위칭 방식 등이 존재한다.

각각의 클라우드 데이터센터의 관리시스템(121, 131, 141)은 각 데이터센터 내에서의 멀티테넌트 네트워킹 환경을 제공하기 위해 가상머신 또는 가상 컨테이너가 물리적으로 서로 다른 서버에 생성된 경우라 할지라도 가상 스위치, 가상 라우터 및/또는 데이터센터 내의 물리적인 L2/L3 스위치를 제어함으로써, 마치 하나의 L2 네트워킹 환경 또는 가상 라우터를 통한 L3 네트워킹 서비스 환경을 보장하고, 서로 다른 테넌트간 트래픽이 혼재되지 않도록 논리적으로 격리된 네트워킹 환경을 제공한다. 대표적인 멀티테넌트 네트워킹을 제공하는 방식으로는 VLAN, VxLAN, NVGRE 등의 오버레이 기술을 꼽을 수 있다.

한편, 클라우드 간 확장된 멀티테넌트 네트워킹 환경을 제공하고자 하는 경우에는 글로벌 클라우드 데이터센터 관리시스템(Global Cloud Controller, 160)이 VPN(Virtual Private Network) 또는 SDN 기술을 기반으로 각 단위 클라우드 데이터센터들(111, 112, 113)와의 협업을 통해 클라우드간 멀티테넌트 환경을 확장 제공할 수 있다. 이를 통해 사용자는 실제로 광역 지역에 분산되어 구축된 복수의 클라우드 데이터센터를 통해 가상 인프라 서비스를 제공받더라도, 마치 하나의 인프라 상에서 서비스를 제공받는 것처럼 멀티테넌트 인프라를 동적으로 이용할 수 있다.

예컨대, 멀티테넌트 네트워크(171)는 데이터센터(DC1)의 가상머신(122), 데이터센터(D2)의 가상머신(135), 및 데이터센터(DC3)의 가상머신들(142, 143)을 이용하여 가상 멀티테넌트 네트워킹 환경을 제공하며, 멀티테넌트 네트워크(172)는 데이터센터(DC1)의 가상머신들(123, 124, 125)과 데이터센터(DC2)의 가상머신(132)를 이용하여 가상 멀티테넌트 네트워킹 환경을 제공할 수 있다. 한편, 멀티테넌트 네트워크(173)은 단일 데이터센터(DC2)의 가상머신들(133, 134)을 이용하여 가상 멀터테넌트 네트워킹 환경을 제공한다.

도 2는 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크의 제공 개념을 설명하기 위한 개념도이다.

도 2를 참조하면, 임의의 지역에 클라우드 A가 구축되어 있고, 다른 한 지역에 클라우드 B가 구축되어 있는 경우가 예시되어 있다. 이때, 클라우드 A와 클라우드 B에는 각각의 클라우드 관리 시스템(210 또는 230)이 존재할 수 있다. 즉, 도 2에서의 클라우드 관리 시스템은 앞서 도 1에서 설명된 단위 클라우드 데이터 센터의 관리시스템(local could controller)에 대응될 수 있다. 각각의 클라우드 관리 시스템(210 또는 230)은 대응되는 클라우드 내의 물리 자원(서버, 네트워크 장비, 스토리지 등)은 물론 가상 자원(가상 머신 또는 가상 컨테이너, 가상 스위치, 가상 라우터 등의 가상 네트워크 장비, 가상 스토리지 등)을 제어하여 각 클라우드를 기반으로 한 클라우드 서비스를 제공할 수 있다.

예컨대, 어떤 사용자가 클라우드 A에 10.10.0.0/24 대역의 가상 네트워크 상에 두 개의 가상머신을 생성해 줄 것을 요청한 경우, 클라우드 A의 클라우드 관리 시스템(210)은 클라우드 A의 물리자원과 가상자원을 제어하여 가상 라우터와 가상 네트워크 그리고 가상머신을 두 개 생성하여 제공하고, 가상머신은 가상 라우터와 클라우드의 외부 게이트웨이를 통해 외부의 사용자 또는 서버와의 네트워킹을 할 수 있다.

그러나, 클라우드 A와 B에 각각 동일한 사용자 또는 사용자 그룹(테넌트)의 가상 인프라가 생성되어 있거나 생성을 요청하는 경우를 가정한다면, 클라우드 A의 10.10.0.3의 IP 주소를 부여받은 가상머신(211)이 클라우드 B의 20.10.0.5의 IP 주소를 부여받은 가상머신(231)에 연결할 방법은 없다. 그 이유는 각 가상 인프라의 네트워크가 사설 IP 주소 대역으로 구성이 되고, 클라우드 A와 B 사이에는 이 사설 IP 주소로는 연결성을 제공할 수 없기 때문이다. 만일, 원격으로 연결하고자 하는 경우에는 클라우드 B의 20.10.0.5의 가상머신(231)에 추가로 공용 IP 주소(예, 222.10.0.5)를 할당한 다음 DNAT(Destination Network Address Translation) 기능(즉, 222.10.0.5 주소에서 20.10.0.5 주소로의 주소 변환) 등을 제공해야 한다.

그러나, 이는 클라우드 A의 가상머신 뿐만 아니라 누구든 클라우드 B의 가상머신에 접근할 수 있음을 의미하며, 클라우드 A와 B 사이에 사용자를 위한 독립적인(즉, 격리된) 가상 네트워크를 제공하는 목적에 위배되는 것이다.

한편, 클라우드 A와 B의 가상 인프라를 패킷광전송 네트워크(240)를 통해 연결하는 독립적인 가상 멀티테넌트 네트워크를 제공하기 위해서는 글로벌 서비스 오케스트레이션 시스템(220) 및 패킷광전송 제어시스템(250)과 같은 추가적인 구성요소를 필요로 한다. 경우에 따라서는 패킷광전송 제어시스템(250)이 글로벌 서비스 오케스트레이션 시스템(220)의 부분 기능 모듈로서 포함되어 구성될 수도 있다. 여기에서, 글로벌 서비스 오케스트레이션 시스템(220)은 지역적으로 분산되어 있는 각 클라우드 데이터센터의 클라우드 관리 시스템(예컨대, 210, 230)을 통해 가상 인프라 서비스를 통합적으로 제어 관리하는 동시에, 클라우드 간 물리적 네트워크 장비를 제어하여 클라우드 간 가상 네트워크를 제어 관리할 수 있는 기능을 가진다. 클로벌 서비스 오케스트레이션 시스템(220)은 앞서 도 1에서 설명된 글로벌 클라우드 데이터센터 관리시스템(global cloud controller)에 대응될 수 있다.

일례로서, 클라우드 A에 존재하는 사용자의 10.10.0.0/24 대역의 가상 인프라와 클라우드 B에 있는 사용자의 20.10.0.0/24 대역의 가상 인프라를 가상 멀티테넌트 네트워크로 상호 연결하고자 하는 경우, 우선 글로벌 서비스 오케스트레이션 시스템(220)은 각 클라우드 관리 시스템(210, 230)을 통해 클라우드 A와 B에 존재하는 사용자의 가상 인프라간 IP 주소가 중복되지 않도록 해야 한다. 또한, 클라우드 A의 10.10.0.0/24 대역의 가상 머신이 클라우드 B의 20.10.0.0/24 대역의 가상 머신에 (또는 그 반대의 방향으로) 별도의 NAT 등의 방법을 거치지 않고 직접 연결성을 제공할 수 있어야 한다. 이를 위해 어느 한쪽의 가상 인프라에 존재하는 가상머신이 원격의 가상 인프라에 존재하는 가상머신에 접근하는 트래픽은 별도의 라우팅 규칙을 통해 패킷광전송 네트워크를 통해 전달될 수 있도록 각 클라우드의 가상 라우터와 외부 게이트웨이를 제어할 수 있어야 하며, VLAN ID 등과 같은 별도의 가상 네트워크 식별 방식을 통해 패킷광전송 네트워크로 유입되는 트래픽 중 사용자의 특정 가상 네트워크가 다른 트래픽과 구별되어 처리될 수 있도록 보장해야 하며, 필요한 경우 각 트래픽별로 별도의 서비스 품질(QoS, Quality of Service) 제어 정책을 적용할 수도 있어야 한다.

좀 더 구체적인 일례로서, 클라우드 A의 IP 주소(10.10.0.3)이 부여된 가상머신(211)이 클라우드 B의 IP 주소(20.10.0.5)이 부여된 가상머신(231)에 접속하는 경우, 가상머신(211)에서는 송신지 주소(source address)는 10.10.0.3, 목적지 주소(destination address)는 20.10.0.5로 설정된 패킷을 내보내며, 클라우드 A에서의 가상 네트워크를 구분하기 위한 테넌트 네트워크 제공 방식에 따라 VLAN, VxLAN, NVGRE 등의 오버레이 기술을 접목하여 해당 패킷을 10.10.0.1의 IP 주소를 가지는 가상 라우터(215)까지 전달한다. 이때, 가상 라우터(215)의 인터페이스에는 가상 네트워크 구분을 위한 오버레이는 제거된 패킷이 전달된다. 상술된 구간은 클라우드 내에서 가상 네트워크 구분을 위한 오버레이 처리/적용 구간으로 정의될 수 있다(도 2에서 P1으로 표시).

패킷을 전달받은 가상 라우터(215)는 가상 라우터(215)에 설정된 라우팅 테이블(routing table)의 규칙에 따라 20.10.0.0/24 대역의 주소를 목적지로 하는 패킷은 클라우드 간 가상 테넌트 네트워크 환경 내의 트래픽에 속하는 패킷임을 인지하고, 인터넷 등의 단순 외부망으로 연결되는 외부 게이트웨이 인터페이스가 아닌, 패킷광전송 네트워크의 클라우드 간 가상 테넌트 네트워크 연결을 위한 전용의 외부 게이트웨이(217)의 인터페이스로 라우팅한다. 이때 전술한 라우팅 규칙 및 전용의 외부 게이트웨이 인터페이스의 동적 생성 등은 글로벌 서비스 오케스트레이션 시스템(220)의 제어를 받은 클라우드 관리 시스템(210)을 통해 사전에 설정된다. 패킷광전송 네트워크와 연결된 전용의 외부 게이트웨이(217)의 인터페이스로 전달된 패킷은 패킷광전송 네트워크(240)에서의 가상 네트워크를 구분하기 위한 가상 네트워크 식별자(예컨대, VLAN ID, VxLAN ID 등) 등을 추가하여 패킷광전송장비(241)까지 전달된다. 이때 본 구간에서 부여되는 가상 네트워크 식별자(VLAN ID, VxLAN ID 등)는 클라우드 내의 가상 네트워크를 구분하기 위한 가상네트워크 식별자(즉, 앞서 언급된 구간 P1에서 사용된 VLAN ID 또는 VxLAN ID)와는 독립적으로 부여/관리되며, 글로벌 서비스 오케스트레이션 시스템(220)을 통해 설정된다. 상술된 구간은 패킷광전송장비와의 가상 네트워크 식별을 위한 오버레이 처리/적용 구간으로 정의될 수 있다(도 2에서 P2으로 표시).

패킷광전송장비(241)에 전달된 트래픽은 글로벌 서비스 오케스트레이션 시스템(220)에서 사전 설정한 정책에 따라 특정 가상네트워크 식별자(VLAN ID 등)가 부여된 트래픽을 특정 MPLS-TP(Multi-Protocol Label Switching - Transport Profile) 레이블에 매핑하여 목적지 패킷광전송장비(243)로 전달된다. 이때 패킷광전송 네트워크(240) 상에서의 MPLS-TP 레이블 정책 및 종단간 연결정보 또한 사전에 글로벌 서비스 오케스트레이션 시스템(220)에 의해 설정된다. 상술된 구간은 패킷광전송망에서의 가상 네트워크 식별 적용 구간으로 정의될 수 있다(도 2에서 P3으로 표시).

참고로 가상네트워크 식별자(VLAN ID등)와 MPLS-TP 레이블을 매핑하는 방식은 구현 방법에 따라 다양하게 적용될 수 있다. 예를 들어, 가상네트워크 식별자(VLAN ID등)를 제거하고 매핑되는 MPLS-TP 레이블을 추가하는 방식이거나, 또는 가상네트워크 식별자(VLAN ID등)를 제거하지 않은 채 바로 MPLS-TP 레이블을 추가하는 방식이 있을 수 있다.

만일 송신측 패킷광전송장비에서 전자의 방식으로 매핑한 경우에는 수신측 패킷광전송장비에서 MPLS-TP 레이블을 제거하고 이에 매핑되는 VLAN ID(송신측에 부여된 VLAN ID와 동일할 필요는 없으나, 클라우드 B 영역에서는 중복되지 않은 고유값을 갖도록 글로벌 서비스 오케스트레이션 시스템이 관리해야 함)를 다시 추가하는 방식이 제공되며, 후자의 방식인 경우에는 수신측 패킷광전송장비에서 단순히 MPLS-TP 레이블을 제거하면, 송신측에서 부여된 VLAN ID가 지속적으로 가상 테넌트 네트워크를 구분하는 목적으로 사용된다. 따라서, 수신측 패킷광전송장비에서는 MPLS-TP 레이블이 제거되고 이와 매핑되는 VLAN ID로 구분되는 트래픽이 외부 게이트웨이(237)를 통해 클라우드 내부로 전달되는데, 이때 VLAN ID에 따라 전달될 가상 라우터(235) 전용의 외부 게이트웨이(237)의 인터페이스가 결정되고 VLAN ID를 제거한 다음 전달한다. 상술된 구간은 패킷광전송장비와의 가상 네트워크 식별을 위한 오버레이 처리/적용 구간으로 정의될 수 있다(도 2에서 P4로 표시).

마지막으로, 가상 라우터(235)의 전용 외부 게이트웨이 인터페이스로 전달된 트래픽은 송신지 주소가 10.10.0.3이고 목적지 주소가 20.10.0.5인 패킷이므로 가상 라우터의 라우팅 규칙에 따라 목적지 가상머신(231)까지 유효하게 전달될 수 있다. 상술된 구간은 클라우드 내에서 가상 네트워크 구분을 위한 오버레이 처리/적용 구간으로 정의될 수 있다(도 2에서 P5로 표시).

이와 같은 방식은 양방향 네트워킹에 모두 동일하게 적용할 수 있으며, 결국 글로벌 서비스 오케스트레이션 시스템(220)의 통합 제어 정책에 따라 각 클라우드의 관리 시스템(210, 230)과 패킷광전송 네트워크 제어 시스템(250)의 연동을 통해 상기 기술한 방식에 의해 복수의 클라우드간 가상 테넌트 네트워크가 종단간 연결이 제공되며 서비스 품질도 보장할 수 있다.

도 3은 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크를 제공하기 위한 네트워크 노드의 구성을 설명하기 위한 블록도이다.

특히, 도3에서 예시된 네트워크 노드의 구성은 오픈스택(OpenStack) 네트워크 노드 구조에 기반한 것이다. 공개 소프트웨어(Open Source Software) 기반의 클라우드 운영체제인 OpenStack (http://www.openstakc.org) 프로젝트는 현재 글로벌 사실 표준(de Facto standard)의 지위에 이를만큼 전세계적으로 폭넓게 도입/구축/운용되고 있는 클라우드 관리 플랫폼이다.

따라서, 본 명세서에서는 도 2를 통해 설명된 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크 제공 방법을 실행하기 위한 네트워크 노드의 구조를 널리 알려진 OpenStack 환경에 기초하여 구현하는 일실시예를 제시한다. 본 실시예는, OpenStack의 Neutron 프로젝트를 통한 네트워킹 서비스를 제공하는 경우에 쉽게 적용이 가능하며, OpenStack 및 Neutron 프로젝트의 특정 버전에 종속되지 않는다.

일반적으로 OpenStack Neutron 프로젝트를 통한 네트워킹 서비스를 제공하는 구조에서는 기능적으로 클라우드 데이터센터의 서버는 제어 노드(Controller node), 네트워크 노드(Network node), 컴퓨트 노드(Compute node)로 구분된다.

먼저, 제어 노드는 클라우드 관리 시스템이 설치/운용되는 서버 또는 서버군을 의미한다. 즉, 제어 노드는 도 2를 통하여 설명된 클라우드 관리 시스템(210 또는 230)이 설치/운용되는 서버 또는 서버군을 의미할 수 있다.

다음으로, 네트워크 노드는 클라우드 내의 가상 인프라에 DHCP, Virtual Router, VPNaaS(VPN as a Service) 등을 제공하는 동시에 데이터센터 외부망과의 연결을 담당하는 네트워킹 전용의 서버 또는 서버군을 의미한다. 즉, 네트워크 노드는 도 2를 통하여 설명된 가상 라우터(215, 315)가 설치/운용되는 서버 또는 서버군을 의미할 수 있다.

마지막으로, 컴퓨트 노드는 사용자가 요청한 가상머신 또는 가상 컨테이너가 생성되는 서버군을 의미한다. 즉, 컴퓨트 노드는 도 2를 통하여 설명된 가상머신(211 또는 231)이 설치/운용되는 서버 또는 서버군을 의미할 수 있다.

본 명세서에서는 클라우드간 가상 테넌트 네트워크 제공을 위해 실질적으로 발명이 적용되는 네트워크 노드만을 중심으로 기술하기로 하며, 그 외 제어 노드와 컴퓨트 노드 등에 대해서는 OpenStack 프로젝트의 문서로 대체한다. 또한, 클라우드 데이터센터에는 소규모인 경우 하나의 네트워크 노드 또는 고가용성 등을 보장하기 위해 복수의 네트워크 노드군을 구성할 수 있으나, 설명의 편의를 위하여 본 명세서에서는 네트워크 노드가 하나인 경우만을 기준으로 일실시예를 설명하며, 복수의 네트워크 노드군인 경우에도 동일하게 확장 적용될 수 있다.

추가로 인터넷망에 연결되는 물리적 네트워크 및 네트워크 인터페이스가 둘 이상 존재하는 경우, 도 3을 통하여 후술될 외부 브릿지(external bridge)에 있는 qg-AAA, qg-BBB 포트 등의 가상 라우터 게이트웨이 포트들은 외부 브릿지가 아닌 통합 브릿지(integration bridge) 상에 생성되고, 외부 브릿지와는 phy-br-ex 및 int-br-ex 패치(patch) 포트를 통해 전달되는 형상을 가질 수도 있다. 단, 본 일실시예에서는 각각 외부망 하나당 하나의 인터페이스만을 가정하며, 복수개의 물리 네트워크에 연결되는 경우에는 전술한 방식과 같이 쉽게 변경/적용될 수 있다.

도 3을 참조하면, 클라우드 데이터센터의 네트워크 노드(300)는 가상머신이 생성되는 컴퓨트 노드군(331)과 연결되는 클라우드 내부 데이터망(330), 클라우드 내부의 가상머신과 데이터센터 외부의 사용자 또는 서버 등의 연결성을 제공하기 위한 인터넷망(340), 그리고 본 발명에서 제시하는 클라우드 간 멀티테넌트 네트워크 제공 및 연결을 위한 패킷 광전송망(350)과 연결되어 있다.

참고로 일반적인 OpenStack 기반의 클라우드 데이터센터 구축의 경우 패킷광전송망과의 연결 및 내부 L2 전송 브릿지(transport bridge)는 존재하지 않으며, 이 부분이 본 발명에서의 목적을 달성하기 위해 추가 제시된 구조 및 방법에 해당된다. 따라서, 본 명세에서는 OpenStack 네트워크 노드 구조의 자세한 기능 및 동작 설명은 제외하고, 본 발명의 목적을 달성하기 위한 부분만을 중심으로 기술한다.

이하의 설명에서, 도 3에서 예시되는 네트워크 노드(300)는 도 2에서 설명된 클라우드 A측의 가상 라우터(215) 및 클라우드 B측의 가상 라우터(235)에 대응되는 것으로 이해될 수 있다. 먼저, 네트워크 노드(300)가 클라우드 A측의 가상 라우터(215)인 경우를 위주로 구체적인 구성과 동작이 설명된다.

클라우드 A에 생성된 10.10.0.0/24 대역의 가상머신(예컨대, IP 주소(10.10.0.3)를 가진 도 2에서의 가상머신(211))이 클라우드 B의 20.10.0.0/24 대역의 가상머신(예컨대, IP 주소(20.10.0.5)를 가진 도 2에서의 가상머신(231))과 클라우드 간 가상 멀티테넌트 네트워크를 확장하여 통신하고자 하는 경우, 글로벌 서비스 오케스트레이션 시스템(220)으로부터 전달된 제어 정책에 따라 클라우드 A의 네트워크 노드에는 서브넷의 게이트웨이인 10.10.0.1의 인터페이스가 가상 라우터 네임스페이스 EFGH의 qr-ccc 포트(301)로 생성되고, 클라우드 B의 20.10.0.0/24 대역으로의 연결을 위한 전용의 가상 라우터 인터페이스 tr-DDD 포트(302)가 가상 라우터의 인터페이스로 생성된다.

이때 qr-ccc 포트(301)는 네트워크 노드의 통합 브릿지(integration bridge, br-int)에 연결되며, tr-DDD 포트(302)는 패킷광전송망으로의 L2 스위칭 및 VLAN 헤더를 처리할 전송 브릿지(transport bridge, br-tr)에 연결된다. 이와 함께 가상 라우터 네임스페이스 EFGH에는 20.10.0.0/24를 목적지로 하는 패킷을 tr-DDD(302) 포트로 라우팅하도록 새로운 규칙이 라우팅 테이블에 추가된다. 또한, 패킷광전송망에서 특정 테넌트의 패킷광전송장비간 MPLS-TP 네트워킹에 매핑하기 위한 VLAN ID 부여 정책이 전송 브릿지(br-tr)의 트래픽 플로우 처리 규칙으로 새로 추가된다. 즉, 예를 들면, tr-DDD 포트(302)로 유입된 트래픽은 VLAN ID=3을 추가하여 if-4 포트(303)로 스위칭되도록 하고, 반대로 if-4 포트(303)로 유입된 트래픽이 VLAN ID=3인 경우에는 VLAN 헤더를 제거하고 tr-DDD 포트(302)로 스위칭되도록 하는 트래픽 플로우 처리 규칙이 정의된다.

이상의 간단한 설정 과정이 글로벌 서비스 오케스트레이션 시스템(220)의 제어 하에 클라우드 A와 클라우드 B에 각각 적용되면, 두 클라우드 간 설정된 가상 테넌트 네트워크를 통해 통신이 가능하다.

앞서 도 2를 통해서 설명된 일 실시예와 도 3의 네트워크 노드 구성을 병행 참조하여 살펴보면, 클라우드 A의 IP 주소(10.10.0.3)를 가진 가상머신(211)이 목적지 IP 주소를 가상머신(231)의 IP 주소(20.10.0.5)로 하여 패킷을 내보내면, 클라우드 A의 클라우드 데이터망에서 가상 네트워크를 구분하기 위한 VxLAN 헤더가 부가된 트래픽이 네트워크 노드의 Interface 2를 통해 터널 브릿지(tunnel bridge, br-tun)로 전달된다. 터널 브릿지(br-tun)에 유입된 트래픽은 이미 터널 브릿지(br-tun)에 설정된 매핑 규칙에 따라 가상 네트워크를 구분하기 위한 식별자인 VxLAN 헤더를 제거하고 대신 VLAN ID를 추가하여 통합 브릿지(br-int)로 전달된다. 통합 브릿지(br-int)에 전달된 트래픽은 VLAN ID를 통해 가상 네트워크를 식별하고, VLAN 헤더를 삭제한 다음 10.10.0.1의 주소를 갖는 라우터 인터페이스인 qr-CCC 포트(301)로 트래픽을 전달한다(즉, 도 2의 구간 P1에 해당).

가상 라우터에서는 목적지의 주소가 20.10.0.0/24 대역에 해당되므로 새롭게 추가된 tr-DDD 포트(302)로 라우팅이 결정되며, 전송 브릿지(br-tr)에서는 새롭게 추가된 트래픽 플로우 처리 규칙에 따라 VLAN ID=3을 추가한 다음, Interface 4를 통해 외부 게이트웨이와 연결된 패킷광전송장비까지 전달된다(즉, 도 2의 구간 P2에 해당).

패킷광전송장비에 전달된 트래픽은 설정된 VLAN ID와 MPLS-TP 레이블 매핑 정보에 따라 MPLS-TP 헤더를 추가하여 목적지 패킷광전송장비까지 전달하며, 수신측 패킷광전송장비는 MPLS-TP 레이블 정보를 바탕으로 매핑되는 VLAN ID를 식별한 다음, MPLS-TP 헤더를 제거하고 VLAN ID=1024를 추가한다(즉, 도 2의 구간 P3에 해당).

다음으로, 네트워크 노드(300)가 클라우드 B측의 가상 라우터(235)인 경우를 위주로 구체적인 구성과 동작이 설명된다.

수신측 패킷광전송장비에서 VLAN ID=1024가 부여된 트래픽이 외부 게이트를 통해 클라우드 B의 전송 브릿지까지 전달되면, 클라우드 B의 전송 브릿지에서는 설정된 트래픽 플로우 처리 규칙에 따라 VLAN ID=1024인 패킷의 VLAN 헤더를 제거하고 tr-XXX 포트를 통해 가상 라우터 네임스페이스로 패킷을 전달한다(즉, 도 2의 구간 P4에 해당).

가상 라우터의 tr-XXX 인터페이스로 전달된 트래픽은 목적지 주소가 20.10.0.5 이므로 가상 라우터의 라우팅 규칙에 따라 20.10.0.1의 주소를 갖는 라우터 인터페이스인 qr-YYY 포트로 트래픽이 전달되며, 이 트래픽은 qr-YYY 포트가 연결된 Integration Bridge와 Tunnel Bridge를 거쳐 목적지 가상머신까지 유효하게 전달된다(즉, 도 2의 구간 P5에 해당).

도 4는 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크 서비스를 제공하기 위한 오픈스택 환경 구성 절차를 설명하기 위한 흐름도이다.

도 4에서 예시되는 방법은 기본적인 OpenStack 기반의 클라우드 환경을 구성하는 것과 큰 차이없이 추가적인 환경 구성으로 충분히 본 발명의 일 실시예에서 제안하는 클라우드 간 멀티테넌트 네트워크 서비스 제공 방법을 실현할 수 있도록 하는 방법이다.

즉, 먼저 클라우드 관리 시스템인 OpenStack 제어노드를 설치함에 있어서 기본적인 설치/구성 절차는 동일하게 진행하되(S410), 본 발명에 따른 패킷광전송 네트워크를 통한 멀티테넌트 네트워크 제공 서비스(POTNaaS; Packet Optical Transport Network as a Service, 이하 'POTNaaS'로 약칭)의 제공여부를 판단하고(S420), POTNaaS를 제공하고자 하는 경우에는 본 발명의 기능을 Neutron 확장 서비스로서 구현한 모듈을 Neutron 설치시 추가로 설치/설정하고 관련 DB 스키마(schema)를 업데이트하는 것으로서 간단히 서비스를 제공할 수 있다(S430).

OpenStack 제어 노드의 설치 이후, 네트워크 노드 설치 및 설정함에 있어서도 기본적인 설치/구성 절차를 동일하게 진행하되(S440), POTNaaS의 제공 여부를 판단하여(S450), 만일 POTNaaS를 제공하고자 하는 경우에는 패킷광전송 네트워크와의 연결성을 제공하기 위한 전송 브릿지(transport bridge)를 네트워크 노드에 추가로 생성하고, 노드의 물리적 네트워크 인터페이스를 전송 브릿지에 포트로서 추가한다(S460).

다음으로, OpenStack 컴퓨트 노드군의 설치 및 설정(S470)이나 기타 클라우드 서비스를 설치하는 것(S480)으로 전체 OpenStack 기반의 클라우드 서비스 환경 구성을 완성할 수 있다.

도 5는 본 발명의 일 실시예에 따른 패킷 광전송 네트워크를 통한 클라우드 간 멀티테넌트 네트워크를 생성하는 절차를 설명하기 위한 순서도이다.

도 5에서 예시된 실시예에서는, 앞선 실시예들과 마찬가지로 둘 이상의 클라우드 데이터센터가 OpenStack 기반으로 구축되어 운용이 되고, 클라우드 데이터센터는 지리적으로 분산되어 패킷광전송 네트워크를 통해 상호 네트워킹이 가능한 경우를 가정한다. 또한, 복수의 클라우드 데이터센터와 패킷광전송 네트워크의 통합제어 및 오케스트레이션을 위한 글로벌 서비스 오케스트레이션 시스템이 최상단에 위치하는 것을 가정한다.

먼저 두 클라우드에 각각 10.10.0.0/24와 20.10.0.0/24의 가상 네트워크에 가상머신이 생성되어 있고, 이들 가상 인프라의 원할한 서비스를 위해 가상 라우터를 포함한 기본 네트워킹 서비스는 모두 설정되어 있는 것을 전제한다. 물론 클라우드간 가상 테넌트 네트워크의 생성은 사전에 두 클라우드에 가상 인프라가 생성되어 운용중이어야 하는 것은 아니며, 각 클라우드의 가상 인프라 생성과 동시에 요청을 받아 수행할 수도 있다. 다만 본 명세서에서는 이미 널리 알려진 기본 가상 인프라의 생성에 대한 설명은 생략한다.

사용자가 글로벌 서비스 오케스트레이션 시스템에서 제공하는 API를 통해 두 클라우드의 가상 인프라인 10.10.0.0/24와 20.10.0.0/24를 상호 연결할 수 있는 가상 테넌트 네트워크 인스턴스(POTNaaS 인스턴스)의 생성을 요청하면(S510), 글로벌 서비스 오케스트레이션 시스템은 우선 사용자의 인증 및 권한검증 기능을 수행(S520)한 다음, 요청사항이 유효한지 즉, 두 클라우드에 사용자의 가상 인프라가 존재하고 CIDR 정보가 일치하며 클라우드간 가상 테넌트 네트워크의 생성을 위한 잘못된 또는 누락된 정보가 없는지 검증한다. 글로벌 서비스 오케스트레이션 시스템은 유효성이 검증된 요청에 대해, 각 클라우드의 목적지 CIDR별 VID값을 결정하고, 패킷광전송장비를 통한 MPLS-TP 터널 생성을 위한 레이블 값 및 서비스 품질 파라미터 등을 결정하고, 각 클라우드의 OpenStack 제어 노드와 패킷광전송 제어시스템에 전달하면서 POTNaaS 서비스의 생성을 요청할 수 있다(S530).

먼저, 패킷광전송 제어시스템은 글로벌 서비스 오케스트레이션 시스템으로부터 전달받은 서비스 생성 요청(S531)에 대해 마찬가지로 서비스의 유효성 및 권한 등을 검증하고(S541), 각 클라우드에 연결된 패킷광전송장비에 클라우드별 VID와 MPLS-TP 레이블의 매핑 규칙을 설정한다(S551). 즉, 각 클라우드로부터 패킷광전송장비에 유입되는 트래픽의 VID 값을 바탕으로 어떤 MPLS-TP 터널로 매핑하여 처리할 것인지에 대한 규칙을 설정한다. 추가로 별도의 서비스 품질을 요청한 경우 패킷광전송장비의 종단간 서비스 품질값도 설정한 다음(S561), 그 결과를 글로벌 서비스 오케스트레이션 시스템에 반환한다(S571).

각 클라우드의 OpenStack 제어 노드는 Neutron의 확장 서비스로서 POTNaaS 인스턴스 생성 요청을 글로벌 서비스 오케스트레이션 시스템으로부터 전달받은 다음(S532), 여느 Neutron 서비스와 마찬가지로 서비스의 유효성 및 권한을 검증하고, 유효한 경우 서비스 인스턴스 정보를 DB에 저장한 다음(S542), 가상 라우터의 라우팅 테이블에 추가할 규칙과 Transport Bridge에 추가할 트래픽 플로우 처리 규칙을 생성하고, 로컬 가상 인프라의 CIDR에 해당하는 가상 라우터가 생성되어 있는 네트워크 노드의 L3 에이전트와 L2 에이전트에 각각 생성된 규칙의 추가를 요청한다(S552).

다음으로, 가상 라우터를 제어하는 네트워크 노드의 L3 에이전트는 요청된 정보에 따라 Transport Bridge와의 연결을 위한 새로운 포트(tr-DDD)를 가상 라우터의 인터페이스로서 추가하고, 가상 라우터의 라우팅 테이블에 POTNaaS를 위한 라우팅 규칙을 추가한다(즉, 20.10.0.0/24를 목적지로 하는 트래픽은 tr-DDD 포트로 전달하기 위한 라우팅 규칙)(S553). 그리고 L2 에이전트는 새롭게 추가된 가상 라우터의 인터페이스 포트(tr-DDD)로부터 유입된 트래픽을 위한 VID 처리 및 L2 스위칭 규칙을 Transport Bridge에 추가한다(즉, tr-DDD 포트에서 유입된 트래픽은 VID=3인 VLAN 헤더를 추가한 다음, if-4 포트로 전달하는 규칙과 if-4로부터 유입된 트래픽의 VID=3인 경우 VLAN 헤더를 제거하고 tr-DDD 포트로 전달하는 스위칭 규칙, S563). 이상의 절차를 통해 OpenStack 네트워크 노드에 POTNaaS 서비스를 위한 서비스 인스턴스의 생성이 완료되면 그 결과를 OpenStack 제어노드에 반환하고(S573), OpenStack 제어노드는 최종 결과를 글로벌 서비스 오케스트레이션 시스템에 반환하고 종료한다(S572).

본 발명에 따른 방법들은 다양한 컴퓨터 수단을 통해 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 컴퓨터 판독 가능 매체에 기록되는 프로그램 명령은 본 발명을 위해 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다.

컴퓨터 판독 가능 매체의 예에는 롬(rom), 램(ram), 플래시 메모리(flash memory) 등과 같이 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러(compiler)에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터(interpreter) 등을 사용해서 컴퓨터에 의해 실행될 수 있는 고급 언어 코드를 포함한다. 상술한 하드웨어 장치는 본 발명의 동작을 수행하기 위해 적어도 하나의 소프트웨어 모듈로 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

210, 230: 클라우드 관리 시스템
220: 글로벌 서비스 오케스트레이션 시스템
211, 231: 가상머신
215, 235: 가상라우터
217, 237: 외부 게이트웨이
240: 패킷 광전송 네트워크
241, 242, 243: 패킷 광전송 장비
250: 패킷 광전송 제어 시스템

Claims (1)

1. 패킷 광전송망을 이용한 멀티테넌트 네트워크 서비스 제공 방법으로서,
   제1 클라우드의 가상 라우터가 상기 제1 클라우드의 가상머신으로부터 패킷을 수신하는 단계;
   상기 패킷이 클라우드 간 가상 테넌트 네트워크의 패킷인 경우, 상기 제1 클라우드의 가상 라우터가 상기 패킷을 클라우드 간 가상 테넌트 네트워크 연결을 위한 전용 외부 게이트웨이 인터페이스로 라우팅하는 단계;
   상기 패킷이 패킷 광전송망을 거쳐 제2 클라우드의 외부 게이트웨이 인터페이스를 통하여 상기 제2 클라우드의 가상 라우터로 전달되는 단계; 및
   상기 제2 클라우드의 가상 라우터가 상기 패킷을 상기 제2 클라우드의 가상머신으로 전달하는 단계를 포함하고,
   상기 제1 클라우드와 상기 제2 클라우드 내의 가상 네트워크를 구분하기 위한 가상 네트워크 식별자와는 독립적인 가상 네트워크 식별자가, 상기 패킷 광전송망내에서 상기 패킷에 부여되는 것을 특징으로 하는,
   패킷 광전송망을 이용한 멀티테넌트 네트워크 서비스 제공 방법.

Images